permissions: udev vs. pam_devperm.so

permissions: udev vs. pam_devperm.so

[Frank Steiner]

Hi,

when logging in via kdm on our SuSE, the pam_devperm module sets
permissions and owner of local devices like /dev/hdc (for cdrom). So
if user "bart" logs in, he get

brw-------    1 bart     disk      22,   0 Sep 23  2003 /dev/hdc


But on some events like calling k3b etc., hotplug/udev sometimes jump
in (not always) an re-detect the block device /dev/hdc, thus setting
the permissions back to the defaults:

brw-rw----    1 root     disk      22,   0 Sep 23  2003 /dev/hdc

This stops user bart from accessing the cdrom for burning etc.

Can I tel udev to leave the permission of *existing* nodes untouched?
I figured out that I could set the line in the permissions file to

hdc*:::660

but the drawback is that udev will create /dev/hdc with the defaults
root:root and 600 like defined in udev.conf, and not with root:disk 660
like it should when no local user is logged in.

Any way to achieve that? Like a flag "leave node untouched if it exists"?

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: permissions: udev vs. pam_devperm.so

[Kay Sievers]

On Tue, 2004-10-26 at 08:37 +0200, Frank Steiner wrote:
> when logging in via kdm on our SuSE, the pam_devperm module sets
> permissions and owner of local devices like /dev/hdc (for cdrom). So
> if user "bart" logs in, he get
> 
> brw-------    1 bart     disk      22,   0 Sep 23  2003 /dev/hdc
> 
> 
> But on some events like calling k3b etc., hotplug/udev sometimes jump
> in (not always) an re-detect the block device /dev/hdc, thus setting
> the permissions back to the defaults:
> 
> brw-rw----    1 root     disk      22,   0 Sep 23  2003 /dev/hdc
> 
> This stops user bart from accessing the cdrom for burning etc.
> 
> Can I tel udev to leave the permission of *existing* nodes untouched?
> I figured out that I could set the line in the permissions file to
> 
> hdc*:::660
> 
> but the drawback is that udev will create /dev/hdc with the defaults
> root:root and 600 like defined in udev.conf, and not with root:disk 660
> like it should when no local user is logged in.

Empty fields mean default permissions, so this will not work. udev will
overwrite everything on "add". Only the inode may be preserved, if the
node already exists with the correct major/minor.

> Any way to achieve that? Like a flag "leave node untouched if it exists"?

There is currently no way to tell udev about this. But this job can be
done by a script in /etc/dev.d/. This will work with custom names too.

Best,
Kay



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: permissions: udev vs. pam_devperm.so

[Frank Steiner]

Kay Sievers wrote

> 
>>Any way to achieve that? Like a flag "leave node untouched if it exists"?
> 
> 
> There is currently no way to tell udev about this. But this job can be
> done by a script in /etc/dev.d/. This will work with custom names too.

Thanks, I will try this! If you ever feel like you want to add such a
flag, just do it ;-)

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: permissions: udev vs. pam_devperm.so

[Kay Sievers]

On Tue, Oct 26, 2004 at 02:30:10PM +0200, Frank Steiner wrote:
> Kay Sievers wrote
> 
> >
> >>Any way to achieve that? Like a flag "leave node untouched if it exists"?
> >
> >
> >There is currently no way to tell udev about this. But this job can be
> >done by a script in /etc/dev.d/. This will work with custom names too.
> 
> Thanks, I will try this! If you ever feel like you want to add such a
> flag, just do it ;-)

I don't think that this will work, as there should be a remove event
before you get a new add event and the node will be deleted and recreated
without anything to preserve. You may check the inode number, it should
have changed.

We may come up with something like the RH udev version, to filter out the
remove events for certain devices to cover that broken ide behavior.

Thanks,
Kay


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: permissions: udev vs. pam_devperm.so

[Frank Steiner]

Kay Sievers wrote

> Empty fields mean default permissions, so this will not work. udev will
> overwrite everything on "add". Only the inode may be preserved, if the
> node already exists with the correct major/minor.

Just one comment:
Having "hdc*:root:disk:660" in udev.permissions and calling "udevstart"
will always set /dev/hdc to root:disk and 600. With owner and group
fields empty, udevstart will not change the owner and the group. I'm
not sure if udevstart triggers "add" events, likely not?

With the permission field empty, udevstart will set the permissions
to 000, although udev.conf specifies 0600 as default, so I guess this
is wrong...

cu,
Frank


-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: permissions: udev vs. pam_devperm.so

[Frank Steiner]

Kay Sievers wrote


> I don't think that this will work, as there should be a remove event
> before you get a new add event and the node will be deleted and recreated
> without anything to preserve. You may check the inode number, it should
> have changed.

Ok, I see... So, do you think it was possible to make sth. similar to
pam_devperm? E.g., my /etc/logindevperms has a line

   :0 0600 /dev/dvd:/dev/dvd1:/dev/dvd2:/dev/dvd3

When a user logs in with kdm (/etc/pam.d/kdm defines using pam_devperm.so),
/dev/dvd (i.e., the device this link points to, here: /dev/hdc) will be
set to 600 and the user logging in will be the owner.
Makes sense for a certain set of devices.

Maybe udev could use pam_devperm in a similar way? Or allow a special
keyword like "console" as owner in the permissions file, setting the
user who owns the console as owner of the device (and the default if
no such user currently exists)? This way, devices added after the user
has logged in, could be assigned to the locally logged-in user, too.

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: permissions: udev vs. pam_devperm.so

[Kay Sievers]

On Tue, Oct 26, 2004 at 03:49:12PM +0200, Frank Steiner wrote:
> Kay Sievers wrote
> 
> 
> >I don't think that this will work, as there should be a remove event
> >before you get a new add event and the node will be deleted and recreated
> >without anything to preserve. You may check the inode number, it should
> >have changed.
> 
> Ok, I see... So, do you think it was possible to make sth. similar to
> pam_devperm? E.g., my /etc/logindevperms has a line
> 
>   :0 0600 /dev/dvd:/dev/dvd1:/dev/dvd2:/dev/dvd3
> 
> When a user logs in with kdm (/etc/pam.d/kdm defines using pam_devperm.so),
> /dev/dvd (i.e., the device this link points to, here: /dev/hdc) will be
> set to 600 and the user logging in will be the owner.
> Makes sense for a certain set of devices.
> 
> Maybe udev could use pam_devperm in a similar way? Or allow a special
> keyword like "console" as owner in the permissions file, setting the
> user who owns the console as owner of the device (and the default if
> no such user currently exists)? This way, devices added after the user
> has logged in, could be assigned to the locally logged-in user, too.

The problem is that every distribution has its own concept of "local" or
"console" users, so the best thing seems to call a distribution specific
permission-restore-script from dev.d/.

If this will not work for you, let us know and we will figure something
out.

Thanks,
Kay


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: permissions: udev vs. pam_devperm.so

[Kay Sievers]

On Tue, Oct 26, 2004 at 03:20:40PM +0200, Frank Steiner wrote:
> Kay Sievers wrote
> 
> >Empty fields mean default permissions, so this will not work. udev will
> >overwrite everything on "add". Only the inode may be preserved, if the
> >node already exists with the correct major/minor.
> 
> Just one comment:
> Having "hdc*:root:disk:660" in udev.permissions and calling "udevstart"
> will always set /dev/hdc to root:disk and 600. With owner and group
> fields empty, udevstart will not change the owner and the group. I'm
> not sure if udevstart triggers "add" events, likely not?
> 
> With the permission field empty, udevstart will set the permissions
> to 000, although udev.conf specifies 0600 as default, so I guess this
> is wrong...

Yes, this seems wrong. I will fix that tonight!

Thanks,
Kay


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: permissions: udev vs. pam_devperm.so

[Kay Sievers]

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

On Tue, Oct 26, 2004 at 03:20:40PM +0200, Frank Steiner wrote:
> Kay Sievers wrote
> 
> >Empty fields mean default permissions, so this will not work. udev will
> >overwrite everything on "add". Only the inode may be preserved, if the
> >node already exists with the correct major/minor.
> 
> Just one comment:
> Having "hdc*:root:disk:660" in udev.permissions and calling "udevstart"
> will always set /dev/hdc to root:disk and 600. With owner and group
> fields empty, udevstart will not change the owner and the group. I'm
> not sure if udevstart triggers "add" events, likely not?

Sure, udevstart simulates a "add" event for every device it can find. I
can't reproduce the failure. I expect you have a earlier line matching in
one of your .permissions files.
udev searches the list from the top and the first match will make it. Do
you have "hd*:..." or similar before the "hdc*"?

> With the permission field empty, udevstart will set the permissions
> to 000, although udev.conf specifies 0600 as default, so I guess this
> is wrong...

Yes, it is wrong. We only apply the defaults if we don't match any rule.
The attached patch should fix this.

Thanks,
Kay

[-- Attachment #2: udev-apply-default-perms-01.patch --]
[-- Type: text/plain, Size: 1069 bytes --]

===== namedev.c 1.154 vs edited =====
--- 1.154/namedev.c	2004-10-20 03:59:11 +02:00
+++ edited/namedev.c	2004-10-27 01:46:02 +02:00
@@ -798,11 +798,10 @@
 		set_empty_perms(udev, perm->mode,
 				      perm->owner,
 				      perm->group);
-	} else {
-		set_empty_perms(udev, get_default_mode(),
-				      get_default_owner(),
-				      get_default_group());
 	}
+	set_empty_perms(udev, get_default_mode(),
+			      get_default_owner(),
+			      get_default_group());
 
 	dbg("name, '%s' is going to have owner='%s', group='%s', mode = %#o",
 	    udev->name, udev->owner, udev->group, udev->mode);
===== test/udev-test.pl 1.60 vs edited =====
--- 1.60/test/udev-test.pl	2004-10-18 15:17:42 +02:00
+++ edited/test/udev-test.pl	2004-10-27 01:50:06 +02:00
@@ -550,11 +550,11 @@
 EOF
 	},
 	{
-		desc		=> "permissions tty3:::",
+		desc		=> "permissions tty3::: (default mode applied)",
 		subsys		=> "tty",
 		devpath		=> "/class/tty/tty3",
 		exp_name	=> "tty3",
-		exp_perms	=> "0:0:0",
+		exp_perms	=> "0:0:600",
 		conf		=> <<EOF
 KERNEL="tty3", NAME="tty3"
 EOF

Re: permissions: udev vs. pam_devperm.so

[Frank Steiner]

Kay Sievers wrote


>>Just one comment:
>>Having "hdc*:root:disk:660" in udev.permissions and calling "udevstart"
>>will always set /dev/hdc to root:disk and 600. With owner and group
>>fields empty, udevstart will not change the owner and the group. I'm
>>not sure if udevstart triggers "add" events, likely not?
> 
> 
> Sure, udevstart simulates a "add" event for every device it can find. I
> can't reproduce the failure. I expect you have a earlier line matching in
> one of your .permissions files.
> udev searches the list from the top and the first match will make it. Do
> you have "hd*:..." or similar before the "hdc*"?

No, but I don't see a failure here (except that I wrote the permission
was set to 600. Sorry, it was indeed changed to 660 like defined. Sorry for
the confusion). With your explanation it seems correct that udevstart sets
the owner and permission back to the values defined in the permissions file,
if it triggers an "add" for every device.

>>With the permission field empty, udevstart will set the permissions
>>to 000, although udev.conf specifies 0600 as default, so I guess this
>>is wrong...
> 
> 
> Yes, it is wrong. We only apply the defaults if we don't match any rule.
> The attached patch should fix this.

Yes, that works. Thanks! Now I can just remove the values from the
permission lines for all entries pam_devperm handles on login. And
whenever udev works on one of these devices (like detecting /dev/hdc
as block device after the user logged in), it won't change the permissions
if the device already exists.
So that's indeed the feature I needed :-)

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id\x12065&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel