udev and sysfs permissions

udev and sysfs permissions

[Jon Smirl]

I'm manually chmod'ing a sysfs variable with different permissions.
About half an hour later (no sure of exact time) the variable is reset
back to the permissions the driver created it with. Is udevd doing
this? Can udev control sysfs permissions (I though it only controlled
the device permissions). If not udev, who is changing the permissions
back?

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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Ìk
_______________________________________________
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 and sysfs permissions

[Kay Sievers]

On Thu, 2005-05-19 at 18:02 -0400, Jon Smirl wrote:
> I'm manually chmod'ing a sysfs variable with different permissions.
> About half an hour later (no sure of exact time) the variable is reset
> back to the permissions the driver created it with. Is udevd doing
> this? Can udev control sysfs permissions (I though it only controlled
> the device permissions). If not udev, who is changing the permissions
> back?

The kernel, I think. udev does nothing like that. I don't think that
changing permission of an attribute from userspace will work. You may
need to use:
  sysfs_chmod_file() from inside the kernel to change the permissions in
the sysfs attribute if that is applicable for your use.

Kay



-------------------------------------------------------
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

Re: udev and sysfs permissions

[Greg KH]

On Thu, May 19, 2005 at 06:02:16PM -0400, Jon Smirl wrote:
> I'm manually chmod'ing a sysfs variable with different permissions.

Ouch, don't do that :(

Hm, does the kernel let you do that?  It shouldn't.

You are doing this as root, right?

> About half an hour later (no sure of exact time) the variable is reset
> back to the permissions the driver created it with.

Heh, nice, I like it.

> Is udevd doing this?

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.

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

Re: udev and sysfs permissions

[Jon Smirl]

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. I need read/write access
to the sysfs attributes but it need to be restricted to whoever owns
the device.

What's the right way to implement this?


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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Ìk
_______________________________________________
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 and sysfs permissions

[Greg KH]

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?

> What's the right way to implement this?

we do have a function to change the mode of the file on the fly, but in
general, I think you might need to just write a small helper program to
mediate access properly.

Good luck,

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

Re: udev and sysfs permissions

[Jon Smirl]

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.

If I can't control permissions on these attributes I'll just get rid
of them all and go back to IOCTLs.

The whole point of this design was to remove the need for the Xserver
to run as root. The server instead runs as a process of the logged in
user.

> 
> > What's the right way to implement this?
> 
> we do have a function to change the mode of the file on the fly, but in
> general, I think you might need to just write a small helper program to
> mediate access properly.
> 
> Good luck,
> 
> greg k-h
> 


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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Ìk
_______________________________________________
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 and sysfs permissions

[Jon Smirl]

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? Then
PAM can switch the ownership of the device and all of the marked
attributes will automatically follow.

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

> 
> > The whole point of this design was to remove the need for the Xserver
> > to run as root. The server instead runs as a process of the logged in
> > user.
> 
> Ah, very nice, I didn't realize this.
> 
> thanks,
> 
> greg k-h
> 


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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Ìk
_______________________________________________
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 and sysfs permissions

[Greg KH]

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.

> The whole point of this design was to remove the need for the Xserver
> to run as root. The server instead runs as a process of the logged in
> user.

Ah, very nice, I didn't realize 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

Re: udev and sysfs permissions

[Jon Smirl]

On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > 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.

If the mantra about sysfs attributes being superior to IOCTLs is true,
then anyone who converts to sysfs attributes is going to run into this
problem.  In the IOCTL model permission obviously follows the owner of
the /dev device. There is no parallel for this in the sysfs model.

This is making me want to switch everything back to the IOCTLs since
they are still in place.

I see how group/user sysfs attributes can control things, but there
should some better way to achieve control. That feels awfully clunky
to me.

> 
> thanks,
> 
> greg k-h
> 


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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Ìk
_______________________________________________
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 and sysfs permissions

[Greg KH]

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

Re: udev and sysfs permissions

[Jon Smirl]

On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > 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?

Can the dnotify/inotify support be used inside the kernel?

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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Ìk
_______________________________________________
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 and sysfs permissions

[Jon Smirl]

On 5/20/05, Greg KH <greg@kroah.com> wrote:
> On Fri, May 20, 2005 at 05:40:05PM -0400, Jon Smirl wrote:
> > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > 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.
> >
> > If the mantra about sysfs attributes being superior to IOCTLs is true,
> > then anyone who converts to sysfs attributes is going to run into this
> > problem.  In the IOCTL model permission obviously follows the owner of
> > the /dev device. There is no parallel for this in the sysfs model.
> 
> True.  Hm, let me look into the sysfs code to see if we can just save
> the changed attributes, so that they do not get lost.  That would be the
> simplest solution, right?

That will work. Right now it is random for me from half an hour to
four hours before they get lost.

> 
> thanks,
> 
> greg k-h
> 


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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Ìk
_______________________________________________
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 and sysfs permissions

[Greg KH]

On Fri, May 20, 2005 at 05:41:32PM -0400, Jon Smirl wrote:
> On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > 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?
> 
> Can the dnotify/inotify support be used inside the kernel?

No.


-------------------------------------------------------
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

Re: udev and sysfs permissions

[Greg KH]

On Fri, May 20, 2005 at 05:40:05PM -0400, Jon Smirl wrote:
> On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > 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.
> 
> If the mantra about sysfs attributes being superior to IOCTLs is true,
> then anyone who converts to sysfs attributes is going to run into this
> problem.  In the IOCTL model permission obviously follows the owner of
> the /dev device. There is no parallel for this in the sysfs model.

True.  Hm, let me look into the sysfs code to see if we can just save
the changed attributes, so that they do not get lost.  That would be the
simplest solution, right?

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

Re: udev and sysfs permissions

[Kay Sievers]

On Fri, 2005-05-20 at 17:53 -0400, Jon Smirl wrote:
> On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > On Fri, May 20, 2005 at 05:40:05PM -0400, Jon Smirl wrote:
> > > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > > 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.
> > >
> > > If the mantra about sysfs attributes being superior to IOCTLs is true,
> > > then anyone who converts to sysfs attributes is going to run into this
> > > problem.  In the IOCTL model permission obviously follows the owner of
> > > the /dev device. There is no parallel for this in the sysfs model.
> > 
> > True.  Hm, let me look into the sysfs code to see if we can just save
> > the changed attributes, so that they do not get lost.  That would be the
> > simplest solution, right?
> 
> That will work. Right now it is random for me from half an hour to
> four hours before they get lost.

That's the backing-store which holds the "real" information. If you read
the attribute again after it is removed form the cache, you get the
drivers state not the one in the vfs. Changes from userspace are not
propagated into the sysfs attribute structures, but that shold be
possible.

Kay



-------------------------------------------------------
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

Re: udev and sysfs permissions

[Greg KH]

On Fri, May 20, 2005 at 05:53:33PM -0400, Jon Smirl wrote:
> On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > On Fri, May 20, 2005 at 05:40:05PM -0400, Jon Smirl wrote:
> > > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > > 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.
> > >
> > > If the mantra about sysfs attributes being superior to IOCTLs is true,
> > > then anyone who converts to sysfs attributes is going to run into this
> > > problem.  In the IOCTL model permission obviously follows the owner of
> > > the /dev device. There is no parallel for this in the sysfs model.
> > 
> > True.  Hm, let me look into the sysfs code to see if we can just save
> > the changed attributes, so that they do not get lost.  That would be the
> > simplest solution, right?
> 
> That will work. Right now it is random for me from half an hour to
> four hours before they get lost.

Yes, see my previous comments about how the sysfs backing store works
to explain 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

Re: udev and sysfs permissions

[Greg KH]

On Sat, May 21, 2005 at 12:07:23AM +0200, Kay Sievers wrote:
> On Fri, 2005-05-20 at 17:53 -0400, Jon Smirl wrote:
> > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > On Fri, May 20, 2005 at 05:40:05PM -0400, Jon Smirl wrote:
> > > > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > > > 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.
> > > >
> > > > If the mantra about sysfs attributes being superior to IOCTLs is true,
> > > > then anyone who converts to sysfs attributes is going to run into this
> > > > problem.  In the IOCTL model permission obviously follows the owner of
> > > > the /dev device. There is no parallel for this in the sysfs model.
> > > 
> > > True.  Hm, let me look into the sysfs code to see if we can just save
> > > the changed attributes, so that they do not get lost.  That would be the
> > > simplest solution, right?

Ugh, in trying to figure this out for the past few days, I've gotten no
where at all :(

Maneesh, any chance we could get some help?  The issue is, if a user
changes the owner:group or permissions on a sysfs file, it would be nice
to have those changes stay.  Due to the backing-store changes, over
time, the sysfs files are re-created, and those user-made changes are
lost.  I've poked around in sysfs, and tried to add some new functions
for the vfs to call when an inode is dirty, but had no luck at all in
getting this to work.  Any ideas?

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
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 and sysfs permissions

[Maneesh Soni]

On Thu, May 26, 2005 at 04:09:51PM -0700, Greg KH wrote:
> On Sat, May 21, 2005 at 12:07:23AM +0200, Kay Sievers wrote:
> > On Fri, 2005-05-20 at 17:53 -0400, Jon Smirl wrote:
> > > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > On Fri, May 20, 2005 at 05:40:05PM -0400, Jon Smirl wrote:
> > > > > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > > > > 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.
> > > > >
> > > > > If the mantra about sysfs attributes being superior to IOCTLs is true,
> > > > > then anyone who converts to sysfs attributes is going to run into this
> > > > > problem.  In the IOCTL model permission obviously follows the owner of
> > > > > the /dev device. There is no parallel for this in the sysfs model.
> > > > 
> > > > True.  Hm, let me look into the sysfs code to see if we can just save
> > > > the changed attributes, so that they do not get lost.  That would be the
> > > > simplest solution, right?
> 
> Ugh, in trying to figure this out for the past few days, I've gotten no
> where at all :(
> 
> Maneesh, any chance we could get some help?  The issue is, if a user
> changes the owner:group or permissions on a sysfs file, it would be nice
> to have those changes stay.  Due to the backing-store changes, over
> time, the sysfs files are re-created, and those user-made changes are
> lost.  I've poked around in sysfs, and tried to add some new functions
> for the vfs to call when an inode is dirty, but had no luck at all in
> getting this to work.  Any ideas?
> 

It should be doable. But again this will increase the size of sysfs_dirent 
structure. If I am not wrong we will need to save (persistent) struct iattr 
for each sysfs_dirent there by increasing its size by 52 bytes on i386 and
we will need ->i_op->setattr() and ->i_op->getattr() routines for sysfs. 

Do we need this functionality in all sysfs objects or only for certain type
of sysfs objects?

Maneesh

-- 
Maneesh Soni
Linux Technology Center, 
IBM India Software Labs,
Bangalore, India
email: maneesh@in.ibm.com
Phone: 91-80-25044990


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
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 and sysfs permissions

[Jon Smirl]

On 5/27/05, Maneesh Soni <maneesh@in.ibm.com> wrote:
> It should be doable. But again this will increase the size of sysfs_dirent
> structure. If I am not wrong we will need to save (persistent) struct iattr
> for each sysfs_dirent there by increasing its size by 52 bytes on i386 and
> we will need ->i_op->setattr() and ->i_op->getattr() routines for sysfs.

Could the 52 byte allocation be deferred until someone actually
changes the sysfs attributes? Most attributes won't get changed.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr_______________________________________________
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 and sysfs permissions

[Greg KH]

On Fri, May 27, 2005 at 06:02:28PM +0530, Maneesh Soni wrote:
> On Thu, May 26, 2005 at 04:09:51PM -0700, Greg KH wrote:
> > On Sat, May 21, 2005 at 12:07:23AM +0200, Kay Sievers wrote:
> > > On Fri, 2005-05-20 at 17:53 -0400, Jon Smirl wrote:
> > > > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > > On Fri, May 20, 2005 at 05:40:05PM -0400, Jon Smirl wrote:
> > > > > > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > > > > > 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.
> > > > > >
> > > > > > If the mantra about sysfs attributes being superior to IOCTLs is true,
> > > > > > then anyone who converts to sysfs attributes is going to run into this
> > > > > > problem.  In the IOCTL model permission obviously follows the owner of
> > > > > > the /dev device. There is no parallel for this in the sysfs model.
> > > > > 
> > > > > True.  Hm, let me look into the sysfs code to see if we can just save
> > > > > the changed attributes, so that they do not get lost.  That would be the
> > > > > simplest solution, right?
> > 
> > Ugh, in trying to figure this out for the past few days, I've gotten no
> > where at all :(
> > 
> > Maneesh, any chance we could get some help?  The issue is, if a user
> > changes the owner:group or permissions on a sysfs file, it would be nice
> > to have those changes stay.  Due to the backing-store changes, over
> > time, the sysfs files are re-created, and those user-made changes are
> > lost.  I've poked around in sysfs, and tried to add some new functions
> > for the vfs to call when an inode is dirty, but had no luck at all in
> > getting this to work.  Any ideas?
> > 
> 
> It should be doable. But again this will increase the size of sysfs_dirent 
> structure. If I am not wrong we will need to save (persistent) struct iattr 
> for each sysfs_dirent there by increasing its size by 52 bytes on i386 and
> we will need ->i_op->setattr() and ->i_op->getattr() routines for sysfs. 

Why do we need to increase the size?  We already save the mode in the
sysfs_dirent, right?  Isn't that all that is needed?  When the setattr()
function is called we can modify our s_mode variable.  Or am I missing
something obvious here?

> Do we need this functionality in all sysfs objects or only for certain type
> of sysfs objects?

Well, we don't really know which ones we need it for :(

If it's going to take up 52 extra bytes for every sysfs file in the
tree, that might not be worth it.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
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 and sysfs permissions

[maneesh]

Quoting Greg KH <greg@kroah.com>:

> On Fri, May 27, 2005 at 06:02:28PM +0530, Maneesh Soni wrote:
> > On Thu, May 26, 2005 at 04:09:51PM -0700, Greg KH wrote:
> > > On Sat, May 21, 2005 at 12:07:23AM +0200, Kay Sievers wrote:
> > > > On Fri, 2005-05-20 at 17:53 -0400, Jon Smirl wrote:
> > > > > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > > > On Fri, May 20, 2005 at 05:40:05PM -0400, Jon Smirl wrote:
> > > > > > > On 5/20/05, Greg KH <greg@kroah.com> wrote:
> > > > > > > > > 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.
> > > > > > >
> > > > > > > If the mantra about sysfs attributes being superior to IOCTLs is
> true,
> > > > > > > then anyone who converts to sysfs attributes is going to run into
> this
> > > > > > > problem.  In the IOCTL model permission obviously follows the
> owner of
> > > > > > > the /dev device. There is no parallel for this in the sysfs
> model.
> > > > > > 
> > > > > > True.  Hm, let me look into the sysfs code to see if we can just
> save
> > > > > > the changed attributes, so that they do not get lost.  That would
> be the
> > > > > > simplest solution, right?
> > > 
> > > Ugh, in trying to figure this out for the past few days, I've gotten no
> > > where at all :(
> > > 
> > > Maneesh, any chance we could get some help?  The issue is, if a user
> > > changes the owner:group or permissions on a sysfs file, it would be
> nice
> > > to have those changes stay.  Due to the backing-store changes, over
> > > time, the sysfs files are re-created, and those user-made changes are
> > > lost.  I've poked around in sysfs, and tried to add some new functions
> > > for the vfs to call when an inode is dirty, but had no luck at all in
> > > getting this to work.  Any ideas?
> > > 
> > 
> > It should be doable. But again this will increase the size of sysfs_dirent
> 
> > structure. If I am not wrong we will need to save (persistent) struct iattr
> 
> > for each sysfs_dirent there by increasing its size by 52 bytes on i386
> and
> > we will need ->i_op->setattr() and ->i_op->getattr() routines for sysfs. 
> 
> Why do we need to increase the size?  We already save the mode in the
> sysfs_dirent, right?  Isn't that all that is needed?  When the setattr()
> function is called we can modify our s_mode variable.  Or am I missing
> something obvious here?
>

There are things like uid, gid etc along with the mode which are used in VFS
sys_chown, sys_chgrp, sys_chmod calls. Filesystem is then notified using 
notify_change() routine which ends up calling ->i_op->setattr() method.

struct iattr {
        unsigned int    ia_valid;
        umode_t         ia_mode;
        uid_t           ia_uid;
        gid_t           ia_gid;
        loff_t          ia_size;
        struct timespec ia_atime;
        struct timespec ia_mtime;
        struct timespec ia_ctime;
        unsigned int    ia_attr_flags;
};

> > Do we need this functionality in all sysfs objects or only for certain
> type
> > of sysfs objects?
> 
> Well, we don't really know which ones we need it for :(
> 
> If it's going to take up 52 extra bytes for every sysfs file in the
> tree, that might not be worth it.
> 

I think Jon's suggestion about allocating struct iattr only if somebody
changes the attributes should be of some help here. Let me code it up this
weekend and see how it looks.

Thanks
Maneesh


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
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 and sysfs permissions

[maneesh]

Quoting Jon Smirl <jonsmirl@gmail.com>:

> On 5/27/05, Maneesh Soni <maneesh@in.ibm.com> wrote:
> > It should be doable. But again this will increase the size of
> sysfs_dirent
> > structure. If I am not wrong we will need to save (persistent) struct
> iattr
> > for each sysfs_dirent there by increasing its size by 52 bytes on i386
> and
> > we will need ->i_op->setattr() and ->i_op->getattr() routines for sysfs.
> 
> Could the 52 byte allocation be deferred until someone actually
> changes the sysfs attributes? Most attributes won't get changed.
> 
Yes, this could be one of the options I can try.

Thanks
Maneesh


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
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