Messages in this thread | | | Date | Fri, 8 Oct 1999 11:04:51 -0500 (CDT) | From | "Forever shall I be." <> | Subject | Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device alloc ation) ) |
| |
Jan Echternach wrote:
> On Thu, Oct 07, 1999 at 07:13:07PM -0400, Horst von Brand wrote: > > "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net> said: > > > In message <199910072150.RAA27710@pincoya.inf.utfsm.cl>, Horst von Brand > > > writes > > > | Name one use of configuration files for local permissions/ownership on > > > | Unix/Linux. > > > > SunOS 4: /etc/fbtab > > > Solaris: /etc/logindevperm > > > > No SunOS/Solaris at hand right now. > > > > > Red Hat 6.x: /etc/security/console.perms > > > > Didn't know about that last one. Scares me, to tell the truth. > > Don't be scared of that. Devfs means dynamic devices directory. And > chown/chmod never worked well in dynamic situations. You certainly > don't expect > > chgrp lp /var/spool/lp/* && chown u+rw /var/spool/lp/* > > to produce any permanent results. You have to reconfigure (or even > recompile) the print service to get different permissions. Another > example: Permissions for new mail folders created by my MUA are > compiled into /opt/bin/mutt. Not even a configuration file.
That is a flat out lie. With devfs, you can change the permissions just fine (with chown/chmod/chgrp/whatever utility you feel like using that works with other normal filesystems), and they will stay until the devfs filesystem is unmounted, and possibly even until you reboot, though I haven't tried that, and doubt it a bit... You could expect almost no less from a ramdisk (though it would stay until reboot on a ramdisk unless you reconfigured the ramdisk), or anything else that is stored on volatile media.
> > If /dev is frequently cleaned up by a script and re-populated with > MAKEDEV whenever new hardware gets attached the situation is the same. > The configuration file for permissions/ownership would be MAKEDEV. >
What if you don't like the permissions MAKEDEV gives? devfs comes with a set of permissions that is not unlike the ones in the MAKEDEV script; it doesn't just blindly choose '777' as the permissions.
> It would be enough for devfs to remember permission/ownership changes > of a device file until it gets deleted to retain Unix-style behaviour. > And a reboot can mean deletion of all device files. I don't see > anything wrong with defining access/security policy for hardware > devices in a configuration file.
_IT DOES_ _TRY IT_ Note: pseudo tty devices are perhaps an exception, though I think only the owners of those get changed (devfs by default changes the owner of a pseudo tty to the person who opens a non-opened one, which I consider a good thing, though you may not), and with devfsd you can even change that behavior.
> > The one change that you have to accept (if you decide to use devfs, or > any other method for dynamic device files) is that /dev won't be static > anymore.
Yes, and it's just that, a change...
> > -- > Jan >
-- Zinx Verituse (finger @bliss.penguinpowered.com for pgp/gpg keys)(new jul10/99) pgp9FE5C9747EB8FF329BB13199C4008E67/gpg574673A12184A27A9EC0EDCCE132BCEF921B1558 0"2-1=0>0:1(2<192:0?0;0A0@2=0<0=1.0A2=0<2A0-">:#v_52*,@ 55*-3*\68*-+, v >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |