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