From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Smirl Date: Fri, 20 May 2005 21:11:01 +0000 Subject: Re: udev and sysfs permissions Message-Id: <9e47339105052014113b1af7f8@mail.gmail.com> List-Id: References: <9e47339105051915025188e535@mail.gmail.com> In-Reply-To: <9e47339105051915025188e535@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org On 5/20/05, Greg KH wrote: > On Fri, May 20, 2005 at 10:06:24AM -0400, Jon Smirl wrote: > > On 5/20/05, Greg KH 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. >=20 > video device, fine. sysfs attributes, no. >=20 > > I need read/write access to the sysfs attributes but it need to be > > restricted to whoever owns the device. >=20 > 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. >=20 > > What's the right way to implement this? >=20 > 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. >=20 > Good luck, >=20 > greg k-h >=20 --=20 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=16344&op=CCk _______________________________________________ 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