lkml.org 
[lkml]   [1999]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:1.193 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site