From mboxrd@z Thu Jan 1 00:00:00 1970 From: maneesh@us.ibm.com Date: Sat, 28 May 2005 05:06:30 +0000 Subject: Re: udev and sysfs permissions Message-Id: <1117256790.4297fc56d4756@imap.linux.ibm.com> List-Id: References: <9e47339105051915025188e535@mail.gmail.com> In-Reply-To: <9e47339105051915025188e535@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Quoting 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 wrote: > > > > > > On Fri, May 20, 2005 at 05:40:05PM -0400, Jon Smirl wrote: > > > > > > > On 5/20/05, Greg KH 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