udev lvm permisions

udev lvm permisions

[Geert Geurts]

Hello,
I have created a encrypted lvm home volume for placing personal files,
and using them on different distributions.
I'm using OpenSuse 11 and Ubuntu 8.10 both distributions are configured
to decrypt the HomeVolume on login using pam_mount. The problem is that
the permissions to the HomeVolume are not set correctly by Suse, so the
volume cannot be decrypted and cannot be mounted.
How can I create a udev rule that applies only to one LVM volume?

Thanks,
Geert  
  

Re: udev lvm permisions

[Michal Soltys]

Geert Geurts wrote:
> Hello,
> the permissions to the HomeVolume are not set correctly by Suse, so the
> volume cannot be decrypted and cannot be mounted.
> How can I create a udev rule that applies only to one LVM volume?
> 

You could match by NAME, for example something similar to:

KERNEL="dm*", ACTION="add|change", SUBSYSTEM="block", NAME="<name 
assigned earlier>", OWNER="<something>", GROUP="<something>", 
MODE=<something>

But for that to work, you need some earlier udev rule setting actual 
name - stock udev rules have no device-mapper rules. So it's up to your 
distro's rules or your own. Alternatively, you could just match by uuid:

ACTION!="add|change", GOTO="dm_end"
KERNEL!="dm*", GOTO="dm_end"

PROGRAM="/sbin/dmsetup info -c --noheadings -o uuid -j%M -m%m", 
ENV{DM_UUID}="%c"

ENV{DM_UUID}="<uuid of needed lvm volume>", OWNER=<something>, 
GROUP=<something>, MODE=<something>

LABEL="dm_end"

Then put it into some late-parsed udev rule. Note that uuid reported by 
dmsetup, will look like LVM-<vg uuid><lv uuid> without any dashes.

Re: udev lvm permisions

[Michal Soltys]

Michal Soltys wrote:
> 
> But for that to work, you need some earlier udev rule setting actual 
> name - stock udev rules have no device-mapper rules. So it's up to your 
> distro's rules or your own. Alternatively, you could just match by uuid:
> 
> [...]
> 
> LABEL="dm_end"
> 

Correction - that won't do what you expect it to, without earlier udev 
rules that would name dm device nodes in the same way as vgscan 
--mknodes would. Such rules are of course possible, but a bit more 
complicated and not necessarily pretty.

Re: udev lvm permisions

[Kay Sievers]

On Mon, Dec 15, 2008 at 11:20, Geert Geurts <begeert@gmail.com> wrote:
> I have created a encrypted lvm home volume for placing personal files,
> and using them on different distributions.
> I'm using OpenSuse 11 and Ubuntu 8.10 both distributions are configured
> to decrypt the HomeVolume on login using pam_mount. The problem is that
> the permissions to the HomeVolume are not set correctly by Suse, so the
> volume cannot be decrypted and cannot be mounted.
> How can I create a udev rule that applies only to one LVM volume?

What kind of permissions? The ownership of the block device? Do you
need to mount it as a user, not as root?

Kay

Re: udev lvm permisions

[Geert Geurts]

Hello kay,
Thanks for your reply!
Indeed it's about a logical volume I want to mount as a normal user.

I've already had discussion with Michal Soltys,
he sugested to create a rule according to the following:
ACTION!="add|change", GOTO="dm_end"
KERNEL!="dm*", GOTO="dm_end"

PROGRAM="/sbin/dmsetup info -c --noheadings -o uuid -j%M -m%m", 
ENV{DM_UUID}="%c"

ENV{DM_UUID}="LVM-N28qi20mqjyPR150TYivmJzvkn8zzpi2VEhSFspDTiAxn2GLFC7xJ8Lfh12dmGH0", GROUP="users", MODEf0

LABEL="dm_end"


I've created this rule but it applies to the kernel device... /dev/dm-*.
What I need is a rule that changes the ownership
of /dev/mapper/HomeVolume.

Thats where I stand now,
so any suggestions are welcome!

Greetings,
Geert

 
On Mon, 2008-12-15 at 15:59 +0100, Kay Sievers wrote:
> On Mon, Dec 15, 2008 at 11:20, Geert Geurts <begeert@gmail.com> wrote:
> > I have created a encrypted lvm home volume for placing personal files,
> > and using them on different distributions.
> > I'm using OpenSuse 11 and Ubuntu 8.10 both distributions are configured
> > to decrypt the HomeVolume on login using pam_mount. The problem is that
> > the permissions to the HomeVolume are not set correctly by Suse, so the
> > volume cannot be decrypted and cannot be mounted.
> > How can I create a udev rule that applies only to one LVM volume?
> 
> What kind of permissions? The ownership of the block device? Do you
> need to mount it as a user, not as root?
> 
> Kay

Re: udev lvm permisions

[Kay Sievers]

On Mon, Dec 15, 2008 at 16:24, Geert Geurts <begeert@gmail.com> wrote:
> Thanks for your reply!
> Indeed it's about a logical volume I want to mount as a normal user.
>
> I've already had discussion with Michal Soltys,
> he sugested to create a rule according to the following:
> ACTION!="add|change", GOTO="dm_end"
> KERNEL!="dm*", GOTO="dm_end"
>
> PROGRAM="/sbin/dmsetup info -c --noheadings -o uuid -j%M -m%m",
> ENV{DM_UUID}="%c"
>
> ENV{DM_UUID}="LVM-N28qi20mqjyPR150TYivmJzvkn8zzpi2VEhSFspDTiAxn2GLFC7xJ8Lfh12dmGH0", GROUP="users", MODEf0
>
> LABEL="dm_end"
>
>
> I've created this rule but it applies to the kernel device... /dev/dm-*.
> What I need is a rule that changes the ownership
> of /dev/mapper/HomeVolume.
>
> Thats where I stand now,
> so any suggestions are welcome!

All the device-mapper/lvm tools are disconnected from udev, and mess
around in /dev on their own. No user higher in the layers
udev/HAL/DeviceKit/Desktop has a clue what device-mapper did here.

On many distros you should be able to use the (workaround the issue)
/dev/disk/by-id/dm-{uuid,name}-* links maintained by udev.

Thanks,
Kay

Re: udev lvm permisions

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Mon, 2008-12-15 at 16:47 +0100, Kay Sievers wrote:

> All the device-mapper/lvm tools are disconnected from udev, and mess
> around in /dev on their own. No user higher in the layers
> udev/HAL/DeviceKit/Desktop has a clue what device-mapper did here.
> 
Except on Ubuntu 8.10, which he says he is at least partly using ;)

NAME=="mapper/foo", MODE="<something>", GROUP="<something>"

should work there

Scott
-- 
Scott James Remnant
scott@canonical.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: udev lvm permisions

[Michal Soltys]

Geert Geurts wrote:
> 
> I've created this rule but it applies to the kernel device... /dev/dm-*.
> What I need is a rule that changes the ownership
> of /dev/mapper/HomeVolume.
> 
> Thats where I stand now,
> so any suggestions are welcome!
> 

As I corrected myself earlier - if you really need udev to do so, you 
need rules file that will create the names as lvm would do.

Or you can extend a bit the above rules and make udev create that 
particular device with the name you want, e.g.

ENV{DM_UUID}="<uuid>", NAME:="<something>" GROUP="users", MODE="0660"

This guarantees that no rule later will alter the name. It also assumes 
you're using udev>\x131 and nothing earlier did NAME:= (with 130 and 
earlier, any earlier NAME= or NAME:= assignment was final).
Then - just use /dev/<something> to access your volume however you need.

Or ... you can just add simple chown / chmod somewhere after lvm is 
activated (not very flexible, but definitely simple).


Anyway - I needed similar thing at one of my machines, where squid cache 
uses coss storage. Squid runs unprivileged, but had to access coss 
device directly. I use rules mimicking lvm/dmsetup behaviour though, so 
simple NAME= test was enough in my case. If you're curious - 
http://marc.info/?l=linux-hotplug&m\x122165542423023&q=p3

With that, I have
ACTION="add|change", SUBSYSTEM="block", NAME="mapper/vg0-coss", \
OWNER="squid", GROUP="squid"

Good luck

Re: udev lvm permisions

[David Zeuthen]

On Mon, 2008-12-15 at 15:55 +0000, Scott James Remnant wrote:
> On Mon, 2008-12-15 at 16:47 +0100, Kay Sievers wrote:
> 
> > All the device-mapper/lvm tools are disconnected from udev, and mess
> > around in /dev on their own. No user higher in the layers
> > udev/HAL/DeviceKit/Desktop has a clue what device-mapper did here.
> > 
> Except on Ubuntu 8.10, which he says he is at least partly using ;)
> 
> NAME="mapper/foo", MODE="<something>", GROUP="<something>"
> 
> should work there

And I hope this helps illustrate exactly why we need device-mapper/LVM
to ship with proper udev integration....

    David

Re: udev lvm permisions

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

On Mon, 2008-12-15 at 12:02 -0500, David Zeuthen wrote:

> On Mon, 2008-12-15 at 15:55 +0000, Scott James Remnant wrote:
> > On Mon, 2008-12-15 at 16:47 +0100, Kay Sievers wrote:
> > 
> > > All the device-mapper/lvm tools are disconnected from udev, and mess
> > > around in /dev on their own. No user higher in the layers
> > > udev/HAL/DeviceKit/Desktop has a clue what device-mapper did here.
> > > 
> > Except on Ubuntu 8.10, which he says he is at least partly using ;)
> > 
> > NAME=="mapper/foo", MODE="<something>", GROUP="<something>"
> > 
> > should work there
> 
> And I hope this helps illustrate exactly why we need device-mapper/LVM
> to ship with proper udev integration....
> 
Alasdair and Kay both have the rules we use and the patches ;)

Scott
-- 
Scott James Remnant
scott@canonical.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: udev lvm permisions

[David Zeuthen]

On Mon, 2008-12-15 at 17:06 +0000, Scott James Remnant wrote:
> On Mon, 2008-12-15 at 12:02 -0500, David Zeuthen wrote:
> 
> > On Mon, 2008-12-15 at 15:55 +0000, Scott James Remnant wrote:
> > > On Mon, 2008-12-15 at 16:47 +0100, Kay Sievers wrote:
> > > 
> > > > All the device-mapper/lvm tools are disconnected from udev, and mess
> > > > around in /dev on their own. No user higher in the layers
> > > > udev/HAL/DeviceKit/Desktop has a clue what device-mapper did here.
> > > > 
> > > Except on Ubuntu 8.10, which he says he is at least partly using ;)
> > > 
> > > NAME="mapper/foo", MODE="<something>", GROUP="<something>"
> > > 
> > > should work there
> > 
> > And I hope this helps illustrate exactly why we need device-mapper/LVM
> > to ship with proper udev integration....
> > 
> Alasdair and Kay both have the rules we use and the patches ;)

Maybe I should have added emphasis on "proper" ;-) - e.g. there's a lot
more to this than these patches I think; see the devkit-devel list
archives a list of things that needs fixing... Fortunately there's a
lively discussion there including Alasdair and other device-mapper
developers.

     David

Re: udev lvm permisions

[Kay Sievers]

On Mon, Dec 15, 2008 at 18:06, Scott James Remnant <scott@canonical.com> wrote:
> On Mon, 2008-12-15 at 12:02 -0500, David Zeuthen wrote:
>
>> On Mon, 2008-12-15 at 15:55 +0000, Scott James Remnant wrote:
>> > On Mon, 2008-12-15 at 16:47 +0100, Kay Sievers wrote:
>> >
>> > > All the device-mapper/lvm tools are disconnected from udev, and mess
>> > > around in /dev on their own. No user higher in the layers
>> > > udev/HAL/DeviceKit/Desktop has a clue what device-mapper did here.
>> > >
>> > Except on Ubuntu 8.10, which he says he is at least partly using ;)
>> >
>> > NAME="mapper/foo", MODE="<something>", GROUP="<something>"
>> >
>> > should work there
>>
>> And I hope this helps illustrate exactly why we need device-mapper/LVM
>> to ship with proper udev integration....
>>
> Alasdair and Kay both have the rules we use and the patches ;)

Yep, and they are racy, we discussed that at the time you did that. It
seems to work fine for you though, which is good. But I didn't want to
add that any enterprise release, which we would need to support for
many years. Device-mapper needs _proper_ udev integration, not a
"overwrite each-other and the last one wins" solution. :)

Kay

Re: udev lvm permisions

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Mon, 2008-12-15 at 18:14 +0100, Kay Sievers wrote:

> Yep, and they are racy, we discussed that at the time you did that. It
> seems to work fine for you though, which is good. But I didn't want to
> add that any enterprise release, which we would need to support for
> many years. Device-mapper needs _proper_ udev integration, not a
> "overwrite each-other and the last one wins" solution. :)
> 
I don't agree that there's any race here.


I agree that there's a better long-term solution, but when there are bug
fixes that work, I prefer not to leave the bug open for N years.  (And I
have more than enough things on my own todo list to work on other
people's :p)

Scott
-- 
Scott James Remnant
scott@canonical.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: udev lvm permisions

[Kay Sievers]

On Mon, Dec 15, 2008 at 18:18, Scott James Remnant <scott@canonical.com> wrote:
> On Mon, 2008-12-15 at 18:14 +0100, Kay Sievers wrote:
>
>> Yep, and they are racy, we discussed that at the time you did that. It
>> seems to work fine for you though, which is good. But I didn't want to
>> add that any enterprise release, which we would need to support for
>> many years. Device-mapper needs _proper_ udev integration, not a
>> "overwrite each-other and the last one wins" solution. :)
>>
> I don't agree that there's any race here.

Should be all in the archives, you never responded that time to my concerns. :)

Kay

Re: udev lvm permisions

[Geert Geurts]

Thanks allot everyone for your time!
I don't have time to work on this problem right now I think I'll try
somethings tomorrow. 
Can't I just create a rule something like:
KERNEL="device-mapper", NAME="mapper/HomeGroup-HomeVolume",
group="users", MODEf0

that should work no?

Greetings,
Geert

On Mon, 2008-12-15 at 17:06 +0000, Scott James Remnant wrote:
> On Mon, 2008-12-15 at 12:02 -0500, David Zeuthen wrote:
> 
> > On Mon, 2008-12-15 at 15:55 +0000, Scott James Remnant wrote:
> > > On Mon, 2008-12-15 at 16:47 +0100, Kay Sievers wrote:
> > > 
> > > > All the device-mapper/lvm tools are disconnected from udev, and mess
> > > > around in /dev on their own. No user higher in the layers
> > > > udev/HAL/DeviceKit/Desktop has a clue what device-mapper did here.
> > > > 
> > > Except on Ubuntu 8.10, which he says he is at least partly using ;)
> > > 
> > > NAME="mapper/foo", MODE="<something>", GROUP="<something>"
> > > 
> > > should work there
> > 
> > And I hope this helps illustrate exactly why we need device-mapper/LVM
> > to ship with proper udev integration....
> > 
> Alasdair and Kay both have the rules we use and the patches ;)
> 
> Scott

Re: udev lvm permisions

[Kay Sievers]

On Mon, Dec 15, 2008 at 18:21, Geert Geurts <begeert@gmail.com> wrote:
> Thanks allot everyone for your time!
> I don't have time to work on this problem right now I think I'll try
> somethings tomorrow.
> Can't I just create a rule something like:
> KERNEL="device-mapper", NAME="mapper/HomeGroup-HomeVolume",
> group="users", MODEf0
>
> that should work no?

There is no KERNEL="device-mapper" for your volume, it's just a block
device named "dm*". Also, we should not change kernel device names, if
not needed, but create symlinks to it.

And we should not overwrite /dev/mapper/ links as long as libdevmapper
is not aware of udev poking in its "private" files. Changes to /dev
need to be serialized and atomic in its operations, and two processes
touching the same files just asks for trouble.

Kay

Re: udev lvm permisions

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Mon, 2008-12-15 at 18:19 +0100, Kay Sievers wrote:

> On Mon, Dec 15, 2008 at 18:18, Scott James Remnant <scott@canonical.com> wrote:
> > On Mon, 2008-12-15 at 18:14 +0100, Kay Sievers wrote:
> >
> >> Yep, and they are racy, we discussed that at the time you did that. It
> >> seems to work fine for you though, which is good. But I didn't want to
> >> add that any enterprise release, which we would need to support for
> >> many years. Device-mapper needs _proper_ udev integration, not a
> >> "overwrite each-other and the last one wins" solution. :)
> >>
> > I don't agree that there's any race here.
> 
> Should be all in the archives, you never responded that time to my concerns. :)
> 
I could only find one concern noted, which the code proves is incorrect.
Assuming you mean the time period between stat() and rename(), one or
the other of the syscalls with fail - and both udev and devmapper will
loop and repair the situation.

Scott
-- 
Scott James Remnant
scott@canonical.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: udev lvm permisions

[Kay Sievers]

On Mon, Dec 15, 2008 at 18:59, Scott James Remnant <scott@canonical.com> wrote:
> On Mon, 2008-12-15 at 18:19 +0100, Kay Sievers wrote:
>
>> On Mon, Dec 15, 2008 at 18:18, Scott James Remnant <scott@canonical.com> wrote:
>> > On Mon, 2008-12-15 at 18:14 +0100, Kay Sievers wrote:
>> >
>> >> Yep, and they are racy, we discussed that at the time you did that. It
>> >> seems to work fine for you though, which is good. But I didn't want to
>> >> add that any enterprise release, which we would need to support for
>> >> many years. Device-mapper needs _proper_ udev integration, not a
>> >> "overwrite each-other and the last one wins" solution. :)
>> >>
>> > I don't agree that there's any race here.
>>
>> Should be all in the archives, you never responded that time to my concerns. :)
>>
> I could only find one concern noted, which the code proves is incorrect.
> Assuming you mean the time period between stat() and rename(), one or
> the other of the syscalls with fail - and both udev and devmapper will
> loop and repair the situation.

Yeah, it was something like that. If I remember correctly, also the
setting of the permissions and the selinux context. We added the parts
of these changes of udev, to support such a logic. But the
libdevmapper part didn't look like it covered the possible races,
especially rename dm-rename events, and the case where /dev/mapper/
are symlinks, like they should be in a udev setup. Even when it
usually does not fail in real world setups, in general it's nothing
that we want to support: two independent processes without
synchronization, fight about the same files in /dev. Libdevmapper just
needs to synchronize/integrate with udev in a race-free way instead.

Thanks,
Kay

Re: udev lvm permisions

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On Mon, 2008-12-15 at 19:19 +0100, Kay Sievers wrote:

> Libdevmapper just needs to synchronize/integrate with udev in a
> race-free way instead.
> 
Aggressively agree.

Nothing on the system should be calling mknod() in /dev anymore except
udev, and should instead synchronise with udev itself.  Everything else
is a temporary workaround or hack.

Scott
-- 
Scott James Remnant
scott@canonical.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: udev lvm permisions

[Kay Sievers]

On Mon, Dec 15, 2008 at 19:21, Scott James Remnant <scott@canonical.com> wrote:
> On Mon, 2008-12-15 at 19:19 +0100, Kay Sievers wrote:
>
>> Libdevmapper just needs to synchronize/integrate with udev in a
>> race-free way instead.
>>
> Aggressively agree.
>
> Nothing on the system should be calling mknod() in /dev anymore except
> udev, and should instead synchronise with udev itself.  Everything else
> is a temporary workaround or hack.

Yeah. And the stuff plugging into udev events, the udev rules,
DeviceKit, the Desktop, all they want to know all the symlinks
belonging to the device, proper events, and not search in /dev for
random things. Therefore we need to integrate with udev properly.

In fact, it's good that you started shipping these patches, so it
shows how stuff should work. And it hopefully puts some pressure on
the guys who should fix their stuff after all these years. Hint, hint
to someone in the Cc: list. :)

Kay

Re: udev lvm permisions

[Alasdair G Kergon]

On Mon, Dec 15, 2008 at 07:38:31PM +0100, Kay Sievers wrote:
> In fact, it's good that you started shipping these patches, so it
> shows how stuff should work. And it hopefully puts some pressure on
> the guys who should fix their stuff after all these years. Hint, hint
> to someone in the Cc: list. :)
 
Well let's try to summarise how far we got in those discussions:

1) udev able to query device-mapper to determine what the /dev/mapper
entry should be called.
- udev uses dmsetup.  Sorted.

2) udev able to query device-mapper to determine what the link should be
called.
- udev uses dmsetup, checks for the LVM prefix on the UUID then either
splits the name into components (vgname+lvname+layer) itself (remembering
to unquote doubled hyphens) or calls out to LVM2 to do that.  (There
may be some sequencing issues here.)

3) udev able to determine whether a link needs to exist in /dev/<vgname> or not
- work on the basis that the requirement is having the LVM uuid prefix and
  having no 'layer' in the name.  (This may change when we support internal
  stacking better.)

4) lvm2 able to sleep until udev has completed a particular sequence of async
operations (without second-guessing udev and looking if the right things have
appeared in /dev)
- unresolved.

Alasdair
-- 
agk@redhat.com

Re: [lvm-devel] Re: udev lvm permisions

[Alasdair G Kergon]

On Mon, Dec 15, 2008 at 07:37:53PM +0000, Alasdair G Kergon wrote:
> 1) udev able to query device-mapper to determine what the /dev/mapper
> entry should be called.
> - udev uses dmsetup.  Sorted.
 
BTW Milan sent me a patch today to make name and uuid available in sysfs.

Alasdair
-- 
agk@redhat.com

Re: udev lvm permisions

[David Zeuthen]

On Mon, 2008-12-15 at 19:37 +0000, Alasdair G Kergon wrote:
> On Mon, Dec 15, 2008 at 07:38:31PM +0100, Kay Sievers wrote:
> > In fact, it's good that you started shipping these patches, so it
> > shows how stuff should work. And it hopefully puts some pressure on
> > the guys who should fix their stuff after all these years. Hint, hint
> > to someone in the Cc: list. :)
>  
> Well let's try to summarise how far we got in those discussions:

Thanks for doing so.

> 1) udev able to query device-mapper to determine what the /dev/mapper
> entry should be called.
> - udev uses dmsetup.  Sorted.

Just a small detail, As I said here

http://lists.freedesktop.org/archives/devkit-devel/2008-December/000085.html

I don't think this is sorted until device-mapper / LVM ships with actual
udev rules. Yes, I'm nit-picking, sorry.

    David

Re: udev lvm permisions

[Alasdair G Kergon]

On Mon, Dec 15, 2008 at 03:14:19PM -0500, David Zeuthen wrote:
> > 1) udev able to query device-mapper to determine what the /dev/mapper
> > entry should be called.
> > - udev uses dmsetup.  Sorted.
> Just a small detail, As I said here
> I don't think this is sorted until device-mapper / LVM ships with actual
> udev rules. Yes, I'm nit-picking, sorry.

Sure - I'm not meaning by that that the change has been made:
I'm meaning there are no further technical problems to solve.

LVM2/device-mapper will not ship with the udev rules until *all* those
problems are resolved i.e. until the process works correctly.
 
Alasdair
-- 
agk@redhat.com