Re: udev and sysfs permissions

[Greg KH <greg@kroah.com>]

On Fri, May 20, 2005 at 05:26:09PM -0400, Jon Smirl wrote:
> On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > On Fri, May 20, 2005 at 05:11:01PM -0400, Jon Smirl wrote:
> > > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > On Fri, May 20, 2005 at 10:06:24AM -0400, Jon Smirl wrote:
> > > > > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > > > Nope, the kernel is.  You must have provided enough memory pressure to
> > > > > > push the file out of the dcache, and then when you went to look at it
> > > > > > again, it was created on the fly from scratch again, with the proper
> > > > > > permissions (as the kernel thinks the files have.)  Nice to see it's all
> > > > > > working properly :)
> > > > > >
> > > > > > > Can udev control sysfs permissions (I though it only controlled the
> > > > > > > device permissions).
> > > > > >
> > > > > > No, only the kernel can control sysfs permissions.
> > > > >
> > > > > We were planning on having PAM assign ownership of the video device
> > > > > and sysfs attributes to the logged in user.
> > > >
> > > > video device, fine.  sysfs attributes, no.
> > > >
> > > > > I need read/write access to the sysfs attributes but it need to be
> > > > > restricted to whoever owns the device.
> > > >
> > > > Ick.  what kind of attributes do you want the logged in user to be able
> > > > to change?
> > >
> > > After everyone complained that IOCTLs were so evil and that sysfs
> > > attributes were the way to go, I added a bunch of attributes for
> > > controlling the framebuffer device. Load a fbdev driver and look in
> > > /sys/class/graphics/fb0.
> > >
> > > [jonsmirl@jonsmirl fb0]$ ls
> > > bits_per_pixel  color_map  cursor  device  modes  virtual_size
> > > blank           console    dev     mode    pan
> > > [jonsmirl@jonsmirl fb0]$
> > >
> > > You can change the mode, cursor position, screen size, pan, etc by
> > > writing to sysfs attributes. These attributes need to only be writable
> > > only by the person who owns the device.
> > 
> > Very nice.
> > 
> > > If I can't control permissions on these attributes I'll just get rid
> > > of them all and go back to IOCTLs.
> > 
> > How about two more files, "user" and "group" that are writable only by
> > root that your pam module writes to to set the user and group of the
> > files?  That way the kernel does the modification, and will always keep
> > the proper permissions.
> 
> How about marking sysfs attributes at creation time to say that their
> permissions mimic the permissions assigned to the /dev device?

How can the kernel know what userspace uses to create a /dev node with?

> Then PAM can switch the ownership of the device and all of the marked
> attributes will automatically follow.

Again, how would the kernel learn of this switch?

> That would make things simpler for driver writers if more devices are
> going to follow this model.

I think you are going to be pretty unique here, as no one else has come
up with a situation yet that requires this.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&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