[linux-lvm] disabling udev_sync and udev_rules

[linux-lvm] disabling udev_sync and udev_rules

[Serguei Bezverkhi (sbezverk)]

Hello folks,

While trying to make lvm work within a docker container I came across an issue when all lvcreate/lvremove got stuck indefinetly or until control-c. When I checked process I noticed lvm was waiting on one semaphore, I found that other folks hit similar issue and they fixed it by setting  udev_sync and udev_rules to 0. It also helped my case too.

I would greatly appreciate if you could share your thought if this change in future can potentially have any negative impact.

Thank you

Serguei

Re: [linux-lvm] disabling udev_sync and udev_rules

[Zdenek Kabelac]

Dne 15.3.2016 v 23:31 Serguei Bezverkhi (sbezverk) napsal(a):
> Hello folks,
>
> While trying to make lvm work within a docker container I came across an issue when all lvcreate/lvremove got stuck indefinetly or until control-c. When I checked process I noticed lvm was waiting on one semaphore, I found that other folks hit similar issue and they fixed it by setting  udev_sync and udev_rules to 0. It also helped my case too.
>
> I would greatly appreciate if you could share your thought if this change in future can potentially have any negative impact.
>
> Thank you

Hi


To 'unblock' stuck processes waiting on udev cookie - you could run:

'dmsetup udevcomplete_all'


However the key question is - how you could get stuck.
That may need further debugging.

You would need to expose your OS  version and also version of lvm2 in use.

Non working cookies are bad - and disabling udev sync is even more bad idea...

Regards

Zdenek

Re: [linux-lvm] disabling udev_sync and udev_rules

[Serguei Bezverkhi (sbezverk)]

Hello Zdenek,

Thank you very much for your prompt reply. I am running RH 7.2 with the latest RH kernel update and LVM2 that came out with recent RH update. This issue is 100% reproducible, if you want I can setup a debugging session where you could access my server and take a look at the issue.

BTW running  this 'dmsetup udevcomplete_all' command did not help me and it cannot be a permanent fix.

Please let me know if you are ok for live debugging.

Thank you

Serguei 

-----Original Message-----
From: linux-lvm-bounces@redhat.com [mailto:linux-lvm-bounces@redhat.com] On Behalf Of Zdenek Kabelac
Sent: Tuesday, March 15, 2016 6:56 PM
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] disabling udev_sync and udev_rules

Dne 15.3.2016 v 23:31 Serguei Bezverkhi (sbezverk) napsal(a):
> Hello folks,
>
> While trying to make lvm work within a docker container I came across an issue when all lvcreate/lvremove got stuck indefinetly or until control-c. When I checked process I noticed lvm was waiting on one semaphore, I found that other folks hit similar issue and they fixed it by setting  udev_sync and udev_rules to 0. It also helped my case too.
>
> I would greatly appreciate if you could share your thought if this change in future can potentially have any negative impact.
>
> Thank you

Hi


To 'unblock' stuck processes waiting on udev cookie - you could run:

'dmsetup udevcomplete_all'


However the key question is - how you could get stuck.
That may need further debugging.

You would need to expose your OS  version and also version of lvm2 in use.

Non working cookies are bad - and disabling udev sync is even more bad idea...

Regards

Zdenek


_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] disabling udev_sync and udev_rules

[Steven Dake (stdake)]

On 3/15/16, 3:56 PM, "linux-lvm-bounces@redhat.com on behalf of Zdenek
Kabelac" <linux-lvm-bounces@redhat.com on behalf of
zdenek.kabelac@gmail.com> wrote:

>Dne 15.3.2016 v 23:31 Serguei Bezverkhi (sbezverk) napsal(a):
>> Hello folks,
>>
>> While trying to make lvm work within a docker container I came across
>>an issue when all lvcreate/lvremove got stuck indefinetly or until
>>control-c. When I checked process I noticed lvm was waiting on one
>>semaphore, I found that other folks hit similar issue and they fixed it
>>by setting  udev_sync and udev_rules to 0. It also helped my case too.
>>
>> I would greatly appreciate if you could share your thought if this
>>change in future can potentially have any negative impact.
>>
>> Thank you
>
>Hi
>
>
>To 'unblock' stuck processes waiting on udev cookie - you could run:
>
>'dmsetup udevcomplete_all'
>
>
>However the key question is - how you could get stuck.
>That may need further debugging.
>
>You would need to expose your OS  version and also version of lvm2 in use.
>
>Non working cookies are bad - and disabling udev sync is even more bad
>idea...

Zdeknek,

To expand on what Serguei is doing, he is working on a patch to add
LVM2+Iscsi in a container for the Cinder (block storage AAS) project in
OpenStack.  He is doing this in the upstream repository here:

http://github.com/openstack/klla

The LVM processes are running within a container.  I suspect if the
process is stuck on a semaphore it has something to do with semaphores not
being shared with the host OS, because containers naturally create a
contained environment.  There are solutions for things like sockets, but
not necessarily for things like semaphores for the container to
communicate with the host OS.

Is there another mechanism besides semaphores to get lvm2 to communicate
with udev?  Turning off udev sync side-steps the problem because then udev
is not in the picture.  Some people in our community think this is a
security risk, although we assume the servers are completely secure.

Your advice welcome on how to solve the problem would be mighty nice :)

To see the change in full, check out:

https://review.openstack.org/#/c/291285/


Regards,
-steve

>
>Regards
>
>Zdenek
>
>
>_______________________________________________
>linux-lvm mailing list
>linux-lvm@redhat.com
>https://www.redhat.com/mailman/listinfo/linux-lvm
>read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] disabling udev_sync and udev_rules

[Zdenek Kabelac]

Dne 16.3.2016 v 00:52 Steven Dake (stdake) napsal(a):
>
>
> On 3/15/16, 3:56 PM, "linux-lvm-bounces@redhat.com on behalf of Zdenek
> Kabelac" <linux-lvm-bounces@redhat.com on behalf of
> zdenek.kabelac@gmail.com> wrote:
>
>> Dne 15.3.2016 v 23:31 Serguei Bezverkhi (sbezverk) napsal(a):
>>> Hello folks,
>>>
>>> While trying to make lvm work within a docker container I came across
>>> an issue when all lvcreate/lvremove got stuck indefinetly or until
>>> control-c. When I checked process I noticed lvm was waiting on one
>>> semaphore, I found that other folks hit similar issue and they fixed it
>>> by setting  udev_sync and udev_rules to 0. It also helped my case too.
>>>
>>> I would greatly appreciate if you could share your thought if this
>>> change in future can potentially have any negative impact.
>>>
>>> Thank you
>>
>> Hi
>>
>>
>> To 'unblock' stuck processes waiting on udev cookie - you could run:
>>
>> 'dmsetup udevcomplete_all'
>>
>>
>> However the key question is - how you could get stuck.
>> That may need further debugging.
>>
>> You would need to expose your OS  version and also version of lvm2 in use.
>>
>> Non working cookies are bad - and disabling udev sync is even more bad
>> idea...
>
> Zdeknek,
>
> To expand on what Serguei is doing, he is working on a patch to add
> LVM2+Iscsi in a container for the Cinder (block storage AAS) project in


Hi

Well - this should be the 1st. sentence in the initial email reporting the 
problem.

lvm2 DOES NOT (and CANNOT) work properly inside container.

Devices are not 'containerized' resource.
This is common bug in 'Docker-land' understanding of Linux kernel.
That's where the hacks like not using 'udev' sync comes from.

> OpenStack.  He is doing this in the upstream repository here:
>
> http://github.com/openstack/klla
>
> The LVM processes are running within a container.  I suspect if the
> process is stuck on a semaphore it has something to do with semaphores not
> being shared with the host OS, because containers naturally create a
> contained environment.  There are solutions for things like sockets, but
> not necessarily for things like semaphores for the container to
> communicate with the host OS.
>
> Is there another mechanism besides semaphores to get lvm2 to communicate
> with udev?  Turning off udev sync side-steps the problem because then udev
> is not in the picture.  Some people in our community think this is a
> security risk, although we assume the servers are completely secure.
>
> Your advice welcome on how to solve the problem would be mighty nice :)
>
> To see the change in full, check out:


The proper way to resolve this is - to have some 'system' service doing
device for you and then transporting such device to your container.
Some sort of super-controller daemon.

Device creation is controlled by udev - which runs in your core system.
It's this udev which is processing kernel event and completes cookie and 
unblocks lvm2 command.

But user really should not confuse what is cgrouped process supposed to be 
doing - it really cannot create device (unlike in full virtual VM) - it has 
wide impact over the whole system - so there must be 'upper-level' process 
controlling this in some way and resolving i.e. name conflicts - sync in the 
system you have just one name space - not per-container namespace - and there 
are more and more troubles ahead...

Anyway - my first advice is to active device as service and pass properly 
created device back to your container via some protocol.

Regards


Zdenek

Re: [linux-lvm] disabling udev_sync and udev_rules

[Steven Dake (stdake)]

On 3/16/16, 1:06 AM, "linux-lvm-bounces@redhat.com on behalf of Zdenek
Kabelac" <linux-lvm-bounces@redhat.com on behalf of
zdenek.kabelac@gmail.com> wrote:

>Dne 16.3.2016 v 00:52 Steven Dake (stdake) napsal(a):
>>
>>
>> On 3/15/16, 3:56 PM, "linux-lvm-bounces@redhat.com on behalf of Zdenek
>> Kabelac" <linux-lvm-bounces@redhat.com on behalf of
>> zdenek.kabelac@gmail.com> wrote:
>>
>>> Dne 15.3.2016 v 23:31 Serguei Bezverkhi (sbezverk) napsal(a):
>>>> Hello folks,
>>>>
>>>> While trying to make lvm work within a docker container I came across
>>>> an issue when all lvcreate/lvremove got stuck indefinetly or until
>>>> control-c. When I checked process I noticed lvm was waiting on one
>>>> semaphore, I found that other folks hit similar issue and they fixed
>>>>it
>>>> by setting  udev_sync and udev_rules to 0. It also helped my case too.
>>>>
>>>> I would greatly appreciate if you could share your thought if this
>>>> change in future can potentially have any negative impact.
>>>>
>>>> Thank you
>>>
>>> Hi
>>>
>>>
>>> To 'unblock' stuck processes waiting on udev cookie - you could run:
>>>
>>> 'dmsetup udevcomplete_all'
>>>
>>>
>>> However the key question is - how you could get stuck.
>>> That may need further debugging.
>>>
>>> You would need to expose your OS  version and also version of lvm2 in
>>>use.
>>>
>>> Non working cookies are bad - and disabling udev sync is even more bad
>>> idea...
>>
>> Zdeknek,
>>
>> To expand on what Serguei is doing, he is working on a patch to add
>> LVM2+Iscsi in a container for the Cinder (block storage AAS) project in
>
>
>Hi
>
>Well - this should be the 1st. sentence in the initial email reporting
>the 
>problem.
>
>lvm2 DOES NOT (and CANNOT) work properly inside container.
>
>Devices are not 'containerized' resource.
>This is common bug in 'Docker-land' understanding of Linux kernel.
>That's where the hacks like not using 'udev' sync comes from.

Zdenek,

Just for the sake of the archive, we did manage to get LVM to work inside
a container without modifying the udev sync rules by using --ipc=host to
docker start.  Thanks for the pointers. I hope that other people that run
across this problem can find this thread and use the --ipc=host solution,
since containerized applications are the future and would be bleak without
lvm2 ;)

Regards
-steve


>
>> OpenStack.  He is doing this in the upstream repository here:
>>
>> http://github.com/openstack/klla
>>
>> The LVM processes are running within a container.  I suspect if the
>> process is stuck on a semaphore it has something to do with semaphores
>>not
>> being shared with the host OS, because containers naturally create a
>> contained environment.  There are solutions for things like sockets, but
>> not necessarily for things like semaphores for the container to
>> communicate with the host OS.
>>
>> Is there another mechanism besides semaphores to get lvm2 to communicate
>> with udev?  Turning off udev sync side-steps the problem because then
>>udev
>> is not in the picture.  Some people in our community think this is a
>> security risk, although we assume the servers are completely secure.
>>
>> Your advice welcome on how to solve the problem would be mighty nice :)
>>
>> To see the change in full, check out:
>
>
>The proper way to resolve this is - to have some 'system' service doing
>device for you and then transporting such device to your container.
>Some sort of super-controller daemon.
>
>Device creation is controlled by udev - which runs in your core system.
>It's this udev which is processing kernel event and completes cookie and
>unblocks lvm2 command.
>
>But user really should not confuse what is cgrouped process supposed to
>be 
>doing - it really cannot create device (unlike in full virtual VM) - it
>has 
>wide impact over the whole system - so there must be 'upper-level'
>process 
>controlling this in some way and resolving i.e. name conflicts - sync in
>the 
>system you have just one name space - not per-container namespace - and
>there 
>are more and more troubles ahead...
>
>Anyway - my first advice is to active device as service and pass properly
>created device back to your container via some protocol.
>
>Regards
>
>
>Zdenek
>
>
>_______________________________________________
>linux-lvm mailing list
>linux-lvm@redhat.com
>https://www.redhat.com/mailman/listinfo/linux-lvm
>read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] disabling udev_sync and udev_rules

[Zdenek Kabelac]

Dne 16.3.2016 v 14:37 Steven Dake (stdake) napsal(a):
>
>
> On 3/16/16, 1:06 AM, "linux-lvm-bounces@redhat.com on behalf of Zdenek
> Kabelac" <linux-lvm-bounces@redhat.com on behalf of
> zdenek.kabelac@gmail.com> wrote:
>
>> Dne 16.3.2016 v 00:52 Steven Dake (stdake) napsal(a):
>>>
>>>
>>> On 3/15/16, 3:56 PM, "linux-lvm-bounces@redhat.com on behalf of Zdenek
>>> Kabelac" <linux-lvm-bounces@redhat.com on behalf of
>>> zdenek.kabelac@gmail.com> wrote:
>>>
>>>> Dne 15.3.2016 v 23:31 Serguei Bezverkhi (sbezverk) napsal(a):
>>>>> Hello folks,
>>>>>
>>>>> While trying to make lvm work within a docker container I came across
>>>>> an issue when all lvcreate/lvremove got stuck indefinetly or until
>>>>> control-c. When I checked process I noticed lvm was waiting on one
>>>>> semaphore, I found that other folks hit similar issue and they fixed
>>>>> it
>>>>> by setting  udev_sync and udev_rules to 0. It also helped my case too.
>>>>>
>>>>> I would greatly appreciate if you could share your thought if this
>>>>> change in future can potentially have any negative impact.
>>>>>
>>>>> Thank you
>>>>
>>>> Hi
>>>>
>>>>
>>>> To 'unblock' stuck processes waiting on udev cookie - you could run:
>>>>
>>>> 'dmsetup udevcomplete_all'
>>>>
>>>>
>>>> However the key question is - how you could get stuck.
>>>> That may need further debugging.
>>>>
>>>> You would need to expose your OS  version and also version of lvm2 in
>>>> use.
>>>>
>>>> Non working cookies are bad - and disabling udev sync is even more bad
>>>> idea...
>>>
>>> Zdeknek,
>>>
>>> To expand on what Serguei is doing, he is working on a patch to add
>>> LVM2+Iscsi in a container for the Cinder (block storage AAS) project in
>>
>>
>> Hi
>>
>> Well - this should be the 1st. sentence in the initial email reporting
>> the
>> problem.
>>
>> lvm2 DOES NOT (and CANNOT) work properly inside container.
>>
>> Devices are not 'containerized' resource.
>> This is common bug in 'Docker-land' understanding of Linux kernel.
>> That's where the hacks like not using 'udev' sync comes from.
>
> Zdenek,
>
> Just for the sake of the archive, we did manage to get LVM to work inside
> a container without modifying the udev sync rules by using --ipc=host to
> docker start.  Thanks for the pointers. I hope that other people that run
> across this problem can find this thread and use the --ipc=host solution,
> since containerized applications are the future and would be bleak without
> lvm2 ;)

Hi

I think you still miss the problem. So let me illustrate:

Let's assume you have a 'VG' in your host machine.

Then you let run commands operating on this VG inside your guest-like 
Dockerized container application - this one surely has no access to system 
lvm2 lockdir. So it will access metadata of your VG without using proper 
locking - it may even think it is taking lock - since inside your 'chrooted' 
container the locking will work - but it's different lock then your system 
lvm2 lock - so just useless...

The situation ain't any better if you make special LV for your docker guest 
and then you let guest to create there a PV to use - since your host
unless precisely configured will see and will interact with does metadata as well.

The 'lvm2' solution so far is  'clvmd' but it's well beyond docker as it's 
using dlm locking and needs fair bit of cluster infrastructure.

I'm also not sure if even 'sanlock' would make a docker land easier to accept 
the fact that you can't let to  have 2 independent apps changing/playing with 
metadata without using locking between each other.

 From what you repeat to say here I assume there is no interest to make it - 
right - just make it work with any hack you can find.

So you've been just warned that there is fair bit of complexity running inside 
lvm2 that relies on certain system behavior - and it's not designed to be 
running in container at all and used in a way you try to demonstrate/promote 
as usable.

Regards

Zdenek

Re: [linux-lvm] disabling udev_sync and udev_rules

[Serguei Bezverkhi (sbezverk)]

Hi Zdenek,

See inline marked [SB]

Thank you

Serguei
-----Original Message-----
From: linux-lvm-bounces@redhat.com [mailto:linux-lvm-bounces@redhat.com] On Behalf Of Zdenek Kabelac
Sent: Wednesday, March 16, 2016 11:05 AM
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] disabling udev_sync and udev_rules

Dne 16.3.2016 v 14:37 Steven Dake (stdake) napsal(a):
>
>
> On 3/16/16, 1:06 AM, "linux-lvm-bounces@redhat.com on behalf of Zdenek 
> Kabelac" <linux-lvm-bounces@redhat.com on behalf of 
> zdenek.kabelac@gmail.com> wrote:
>
>> Dne 16.3.2016 v 00:52 Steven Dake (stdake) napsal(a):
>>>
>>>
>>> On 3/15/16, 3:56 PM, "linux-lvm-bounces@redhat.com on behalf of 
>>> Zdenek Kabelac" <linux-lvm-bounces@redhat.com on behalf of 
>>> zdenek.kabelac@gmail.com> wrote:
>>>
>>>> Dne 15.3.2016 v 23:31 Serguei Bezverkhi (sbezverk) napsal(a):
>>>>> Hello folks,
>>>>>
>>>>> While trying to make lvm work within a docker container I came 
>>>>> across an issue when all lvcreate/lvremove got stuck indefinetly 
>>>>> or until control-c. When I checked process I noticed lvm was 
>>>>> waiting on one semaphore, I found that other folks hit similar 
>>>>> issue and they fixed it by setting  udev_sync and udev_rules to 0. 
>>>>> It also helped my case too.
>>>>>
>>>>> I would greatly appreciate if you could share your thought if this 
>>>>> change in future can potentially have any negative impact.
>>>>>
>>>>> Thank you
>>>>
>>>> Hi
>>>>
>>>>
>>>> To 'unblock' stuck processes waiting on udev cookie - you could run:
>>>>
>>>> 'dmsetup udevcomplete_all'
>>>>
>>>>
>>>> However the key question is - how you could get stuck.
>>>> That may need further debugging.
>>>>
>>>> You would need to expose your OS  version and also version of lvm2 
>>>> in use.
>>>>
>>>> Non working cookies are bad - and disabling udev sync is even more 
>>>> bad idea...
>>>
>>> Zdeknek,
>>>
>>> To expand on what Serguei is doing, he is working on a patch to add
>>> LVM2+Iscsi in a container for the Cinder (block storage AAS) project 
>>> LVM2+in
>>
>>
>> Hi
>>
>> Well - this should be the 1st. sentence in the initial email 
>> reporting the problem.
>>
>> lvm2 DOES NOT (and CANNOT) work properly inside container.
>>
>> Devices are not 'containerized' resource.
>> This is common bug in 'Docker-land' understanding of Linux kernel.
>> That's where the hacks like not using 'udev' sync comes from.
>
> Zdenek,
>
> Just for the sake of the archive, we did manage to get LVM to work 
> inside a container without modifying the udev sync rules by using 
> --ipc=host to docker start.  Thanks for the pointers. I hope that 
> other people that run across this problem can find this thread and use 
> the --ipc=host solution, since containerized applications are the 
> future and would be bleak without
> lvm2 ;)

Hi

I think you still miss the problem. So let me illustrate:

Let's assume you have a 'VG' in your host machine.

Then you let run commands operating on this VG inside your guest-like Dockerized container application - this one surely has no access to system
lvm2 lockdir. So it will access metadata of your VG without using proper locking - it may even think it is taking lock - since inside your 'chrooted' 
container the locking will work - but it's different lock then your system
lvm2 lock - so just useless...

[SB] We provide access from the docker container to the host lock file location. So LVM in container is NOT creating a separate lock but use the right one.


The situation ain't any better if you make special LV for your docker guest and then you let guest to create there a PV to use - since your host unless precisely configured will see and will interact with does metadata as well.

The 'lvm2' solution so far is  'clvmd' but it's well beyond docker as it's using dlm locking and needs fair bit of cluster infrastructure.

I'm also not sure if even 'sanlock' would make a docker land easier to accept the fact that you can't let to  have 2 independent apps changing/playing with metadata without using locking between each other.

 From what you repeat to say here I assume there is no interest to make it - right - just make it work with any hack you can find.

So you've been just warned that there is fair bit of complexity running inside
lvm2 that relies on certain system behavior - and it's not designed to be running in container at all and used in a way you try to demonstrate/promote as usable.

Regards

Zdenek

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] disabling udev_sync and udev_rules

[John Stoffel]

So what's to keep a docker container from deleting all your other LVs
that it shouldn't know about?

If I have a VG called coontainers, with a bunch of LVs called c1, c2,
... , cN.

What is to keep c1 from nuking the LV in c2?

John

Re: [linux-lvm] disabling udev_sync and udev_rules

[Serguei Bezverkhi (sbezverk)]

Hi John,

At least in our situation, Dockers do not own LV and nothing prevents in theory LV created by a process in one container, to be removed by another process in another container. It is exactly the same if two processed are trying to do the same thing.  In both cases if a volume is busy no process will be able to remove it.

In our case, dockers are more like process wrapper, it does not holds any resources other than it needs to run this one process.

I hope it clarifies a bit the approach we took.

Thank you

Serguei
  
-----Original Message-----
From: linux-lvm-bounces@redhat.com [mailto:linux-lvm-bounces@redhat.com] On Behalf Of John Stoffel
Sent: Wednesday, March 16, 2016 11:43 AM
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] disabling udev_sync and udev_rules


So what's to keep a docker container from deleting all your other LVs that it shouldn't know about?

If I have a VG called coontainers, with a bunch of LVs called c1, c2, ... , cN.

What is to keep c1 from nuking the LV in c2?

John

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] disabling udev_sync and udev_rules

[Zdenek Kabelac]

Dne 16.3.2016 v 17:17 Serguei Bezverkhi (sbezverk) napsal(a):
> Hi John,
>
> At least in our situation, Dockers do not own LV and nothing prevents in theory LV created by a process in one container, to be removed by another process in another container. It is exactly the same if two processed are trying to do the same thing.  In both cases if a volume is busy no process will be able to remove it.
>
> In our case, dockers are more like process wrapper, it does not holds any resources other than it needs to run this one process.
>
> I hope it clarifies a bit the approach we took.
>

Giving docker container root privileges to execute lvm2 command (or in effect 
any other root commands!) is just not the docker is supposed to be used (IMHO).

You are just making the security hole bigger and bigger...

But I assume there is no way to convince you it's serious mistake with this 
approach...

Regards

Zdenek


>
> -----Original Message-----
> From: linux-lvm-bounces@redhat.com [mailto:linux-lvm-bounces@redhat.com] On Behalf Of John Stoffel
> Sent: Wednesday, March 16, 2016 11:43 AM
> To: LVM general discussion and development <linux-lvm@redhat.com>
> Subject: Re: [linux-lvm] disabling udev_sync and udev_rules
>
>
> So what's to keep a docker container from deleting all your other LVs that it shouldn't know about?
>
> If I have a VG called coontainers, with a bunch of LVs called c1, c2, ... , cN.
>
> What is to keep c1 from nuking the LV in c2?
>
> John
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

Re: [linux-lvm] disabling udev_sync and udev_rules

[Steven Dake (stdake)]

On 3/16/16, 9:53 AM, "linux-lvm-bounces@redhat.com on behalf of Zdenek
Kabelac" <linux-lvm-bounces@redhat.com on behalf of zkabelac@redhat.com>
wrote:

>Dne 16.3.2016 v 17:17 Serguei Bezverkhi (sbezverk) napsal(a):
>> Hi John,
>>
>> At least in our situation, Dockers do not own LV and nothing prevents
>>in theory LV created by a process in one container, to be removed by
>>another process in another container. It is exactly the same if two
>>processed are trying to do the same thing.  In both cases if a volume is
>>busy no process will be able to remove it.
>>
>> In our case, dockers are more like process wrapper, it does not holds
>>any resources other than it needs to run this one process.
>>
>> I hope it clarifies a bit the approach we took.
>>
>
>Giving docker container root privileges to execute lvm2 command (or in
>effect 
>any other root commands!) is just not the docker is supposed to be used
>(IMHO).
>
>You are just making the security hole bigger and bigger...
>
>But I assume there is no way to convince you it's serious mistake with
>this 
>approach...
>
>Regards
>
>Zdenek
Zdenek,

Our project (kolla) assumes the host is completely secured and used for
one purpose (deployed OpenStack).  This is not a general purpose solution
for those that want to share the host with other applications outside of
the scope of one application (OpenStack) per physical machine.

We run the lvm commands via sudo with an appropriate locked down sudoers
file.

Regards,
-steve

>
>
>>
>> -----Original Message-----
>> From: linux-lvm-bounces@redhat.com
>>[mailto:linux-lvm-bounces@redhat.com] On Behalf Of John Stoffel
>> Sent: Wednesday, March 16, 2016 11:43 AM
>> To: LVM general discussion and development <linux-lvm@redhat.com>
>> Subject: Re: [linux-lvm] disabling udev_sync and udev_rules
>>
>>
>> So what's to keep a docker container from deleting all your other LVs
>>that it shouldn't know about?
>>
>> If I have a VG called coontainers, with a bunch of LVs called c1, c2,
>>... , cN.
>>
>> What is to keep c1 from nuking the LV in c2?
>>
>> John
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>
>_______________________________________________
>linux-lvm mailing list
>linux-lvm@redhat.com
>https://www.redhat.com/mailman/listinfo/linux-lvm
>read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/