Re: udev-021 rule based permissions (+patch)

Re: udev-021 rule based permissions (+patch)

[Hyriand]

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

On Wednesday 03 March 2004 16:10, you wrote:
> On Wed, Mar 03, 2004 at 03:15:45PM +0100, Hyriand wrote:
> > Dear Greg,
> >
> > First of all, thanks for your excellent work on udev (and related tools),
> > I really enjoyed giving devfs a big kick and wiping every trace of it
> > from my kernel.
>
> Thanks for your kind words.
>
> > But now for the direct cause of this e-mail, rule-based permissions.
> > Quite simple actually, it adds OWNER, GROUP and MODE fields to the device
> > rules, and applies those if no applicable rule is found in the
> > permissions table. I know this might be against conventions, but it adds
> > some flexibility since you can't change permissions based on a symlink
> > name.
>
> Hm, I don't understand.  What is wrong with the current scheme of using
> the udev.permissions file for this?

An over-simplified case would be a laptop that has a slot in which you can 
insert a cd-recorder or a dvd-rom drive. If the cd-rw is inserted, the group 
of the "hdc" device should be "cdrw" (well, depends on how you arrange 
security of course), and if the dvd-rom drive is inserted, the group should 
be something else. There's currently one way of achieving that, making the 
device name change (cdrom or dvdrom), settings up permissions for that and 
symlinking it to %k (for compatibility reasons), but I thought this was a 
slightly cleaner way (configuration wise) of setting up different permissions 
for a device without having to symlink it.

Or in other words, "hdc" (or whatever other device file) might not always 
refer to the same device, and should have different permissions accordingly.

>
> Also, things like this should be cc: the linux-hotplug-devel mailing
> list so that other udev developers see it.

Ok, I'll attach the patch again and CC it to the mailing list.

>
> thanks,
>
> greg k-h

Hyriand

[-- Attachment #2: udev-021_rule-based-perms.patch --]
[-- Type: text/x-diff, Size: 3324 bytes --]

diff -ru3 udev-021/namedev.c udev-021-hy/namedev.c
--- udev-021/namedev.c	2004-03-03 01:01:33.000000000 +0100
+++ udev-021-hy/namedev.c	2004-03-03 15:04:03.000000000 +0100
@@ -792,6 +792,7 @@
 	struct perm_device *perm;
 	char *pos;
 
+	char mode_set = 0;
 	udev->mode = 0;
 
 	/* find the sysfs_device associated with this class device */
@@ -839,6 +840,25 @@
 				strfieldcat(udev->symlink, " ");
 			}
 
+			if (dev->owner[0] != '\0') {
+				info("configured rule in '%s' at line %i applied, changing owner to '%s'",
+				    dev->config_file, dev->config_line, dev->owner);
+				strfieldcpy(udev->owner, dev->owner);
+			}
+			
+			if (dev->group[0] != '\0') {
+				info("configured rule in '%s' at line %i applied, changing group to '%s'",
+				    dev->config_file, dev->config_line, dev->group);
+				strfieldcpy(udev->group, dev->group);
+			}
+			
+			if (dev->mode_set != 0) {
+				info("configured rule in '%s' at line %i applied, changing mode to '%u'",
+				    dev->config_file, dev->config_line, dev->mode);
+				udev->mode = dev->mode;
+				mode_set = -1;
+			}
+			
 			if (dev->name[0] != '\0') {
 				info("configured rule in '%s' at line %i applied, '%s' becomes '%s'",
 				     dev->config_file, dev->config_line, udev->kernel_name, dev->name);
@@ -865,9 +885,12 @@
 		strfieldcpy(udev->group, perm->group);
 	} else {
 		/* no matching perms found :( */
-		udev->mode = get_default_mode();
-		strfieldcpy(udev->owner, get_default_owner());
-		strfieldcpy(udev->group, get_default_group());
+		if(! mode_set)
+			udev->mode = get_default_mode();
+		if(udev->owner[0] == '\0')
+			strfieldcpy(udev->owner, get_default_owner());
+		if(udev->group[0] == '\0')
+			strfieldcpy(udev->group, get_default_group());
 	}
 	dbg("name, '%s' is going to have owner='%s', group='%s', mode = %#o",
 	    udev->name, udev->owner, udev->group, udev->mode);
Only in udev-021-hy: namedev.ck
diff -ru3 udev-021/namedev.h udev-021-hy/namedev.h
--- udev-021/namedev.h	2004-03-03 01:01:30.000000000 +0100
+++ udev-021-hy/namedev.h	2004-03-03 14:57:55.000000000 +0100
@@ -44,6 +44,9 @@
 #define FIELD_KERNEL		"KERNEL"
 #define FIELD_NAME		"NAME"
 #define FIELD_SYMLINK		"SYMLINK"
+#define FIELD_OWNER		"OWNER"
+#define FIELD_GROUP		"GROUP"
+#define FIELD_MODE		"MODE"
 
 #define ATTR_PARTITIONS		"all_partitions"
 #define PARTITIONS_COUNT	15
@@ -72,6 +75,10 @@
 	char symlink[NAME_SIZE];
 	struct sysfs_pair sysfs_pair[MAX_SYSFS_PAIRS];
 	int partitions;
+	char owner[OWNER_SIZE];
+	char group[GROUP_SIZE];	
+	char mode_set;
+	unsigned int mode;
 	char config_file[NAME_SIZE];
 	int config_line;
 };
diff -ru3 udev-021/namedev_parse.c udev-021-hy/namedev_parse.c
--- udev-021/namedev_parse.c	2004-03-03 01:01:31.000000000 +0100
+++ udev-021-hy/namedev_parse.c	2004-03-03 15:03:40.000000000 +0100
@@ -241,6 +241,22 @@
 				continue;
 			}
 
+			if (strcasecmp(temp2, FIELD_OWNER) == 0) {
+				strfieldcpy(dev.owner, temp3);
+				continue;
+			}
+
+			if (strcasecmp(temp2, FIELD_GROUP) == 0) {
+				strfieldcpy(dev.group, temp3);
+				continue;
+			}
+
+			if (strcasecmp(temp2, FIELD_MODE) == 0) {
+				dev.mode = strtol(temp3, NULL, 8);
+				dev.mode_set = -1;
+				continue;
+			}
+			
 			dbg("unknown type of field '%s'", temp2);
 			dbg("You might be using a rules file in the old format, please fix.");
 			goto error;

Re: udev-021 rule based permissions (+patch)

[Greg KH]

On Wed, Mar 03, 2004 at 04:34:43PM +0100, Hyriand wrote:
> On Wednesday 03 March 2004 16:10, you wrote:
> > On Wed, Mar 03, 2004 at 03:15:45PM +0100, Hyriand wrote:
> > > Dear Greg,
> > >
> > > First of all, thanks for your excellent work on udev (and related tools),
> > > I really enjoyed giving devfs a big kick and wiping every trace of it
> > > from my kernel.
> >
> > Thanks for your kind words.
> >
> > > But now for the direct cause of this e-mail, rule-based permissions.
> > > Quite simple actually, it adds OWNER, GROUP and MODE fields to the device
> > > rules, and applies those if no applicable rule is found in the
> > > permissions table. I know this might be against conventions, but it adds
> > > some flexibility since you can't change permissions based on a symlink
> > > name.
> >
> > Hm, I don't understand.  What is wrong with the current scheme of using
> > the udev.permissions file for this?
> 
> An over-simplified case would be a laptop that has a slot in which you can 
> insert a cd-recorder or a dvd-rom drive. If the cd-rw is inserted, the group 
> of the "hdc" device should be "cdrw" (well, depends on how you arrange 
> security of course), and if the dvd-rom drive is inserted, the group should 
> be something else. There's currently one way of achieving that, making the 
> device name change (cdrom or dvdrom), settings up permissions for that and 
> symlinking it to %k (for compatibility reasons), but I thought this was a 
> slightly cleaner way (configuration wise) of setting up different permissions 
> for a device without having to symlink it.
> 
> Or in other words, "hdc" (or whatever other device file) might not always 
> refer to the same device, and should have different permissions accordingly.

Then provide a different name for the device, which allows you to have
different permissions.  That's the simplest solution for this, correct?

thanks,

greg k-h


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&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

Re: udev-021 rule based permissions (+patch)

[Hyriand]

On Wednesday 03 March 2004 19:41, you wrote:
> On Wed, Mar 03, 2004 at 04:34:43PM +0100, Hyriand wrote:
> > On Wednesday 03 March 2004 16:10, you wrote:
> > > On Wed, Mar 03, 2004 at 03:15:45PM +0100, Hyriand wrote:
> > > > Dear Greg,
> > > >
> > > > First of all, thanks for your excellent work on udev (and related
> > > > tools), I really enjoyed giving devfs a big kick and wiping every
> > > > trace of it from my kernel.
> > >
> > > Thanks for your kind words.
> > >
> > > > But now for the direct cause of this e-mail, rule-based permissions.
> > > > Quite simple actually, it adds OWNER, GROUP and MODE fields to the
> > > > device rules, and applies those if no applicable rule is found in the
> > > > permissions table. I know this might be against conventions, but it
> > > > adds some flexibility since you can't change permissions based on a
> > > > symlink name.
> > >
> > > Hm, I don't understand.  What is wrong with the current scheme of using
> > > the udev.permissions file for this?
> >
> > An over-simplified case would be a laptop that has a slot in which you
> > can insert a cd-recorder or a dvd-rom drive. If the cd-rw is inserted,
> > the group of the "hdc" device should be "cdrw" (well, depends on how you
> > arrange security of course), and if the dvd-rom drive is inserted, the
> > group should be something else. There's currently one way of achieving
> > that, making the device name change (cdrom or dvdrom), settings up
> > permissions for that and symlinking it to %k (for compatibility reasons),
> > but I thought this was a slightly cleaner way (configuration wise) of
> > setting up different permissions for a device without having to symlink
> > it.
> >
> > Or in other words, "hdc" (or whatever other device file) might not always
> > refer to the same device, and should have different permissions
> > accordingly.
>
> Then provide a different name for the device, which allows you to have
> different permissions.  That's the simplest solution for this, correct?
>
> thanks,
>
> greg k-h

Sure, that's a possibility (and creating a symlink to not confuse applications 
that work on both the cdrw and the dvd drive, like mount), but, this adds a 
symlink which clutters /dev.. But I guess I'll just have to live with that :)

Hyriand


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&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