Re: udev and sysfs permissions

[maneesh@us.ibm.com]

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