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