Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 03 Jan 1999 10:52:05 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        freebsd-arch@FreeBSD.ORG
Subject:   Re: DEVFS, the time has come... 
Message-ID:  <199901030252.KAA06791@spinner.netplex.com.au>
In-Reply-To: Your message of "Sat, 02 Jan 1999 12:43:31 %2B0100." <19990102124331.02468@uriah.heep.sax.de> 

next in thread | previous in thread | raw e-mail | index | archive | help
J Wunsch wrote:
> As Mike Smith wrote:
> 
> > I was just discussing this with Eivind; I think that we can comfortably 
> > cover every set of requirements with:
> > 
> >  - a kernel-wide default owner/group/permissions for new nodes, which 
> >    can be overridden by the device driver in response to eg. 
> >    configuration arguments or device-specific concerns.
> 
> I think (and I know i'm not alone with this) that the kernel should
> have no further knowledge of UIDs and GIDs except UID/GID 0:0.
> Everything else violates the POLA in case someone edits her
> /etc/master.passwd and /etc/group (and I hope you don't suggest that
> the kernel might read those files ;-)

Just repeating something I said earlier.  I think it would be better to 
enable drivers to choose a "class" much moreso than permissions.  This 
allows default uid/gid/mode etc to be exported to userland, but still 
comes up with a functional devfs (600, root, wheel) at boot and single 
user.

If we can do a:
  sysctl -w vfs.devfs.class.console.uid=`id -u peter`
and have all past and future console related devices being owned by uid 
433 instead of 0, then I'd be as happy as a clam.  However, doing an 
explicit 'chmod joebloggs /dev/ttyv8' would assign it a uid and sperate it 
from class updates via sysctl.  An /etc/*rc* script would handle setting 
permissions of the default classes at boot, and any explicit overrides.

[I'm somewhat doubtfully letting this repeat through, given that the
concept seems interesting and some people might have lost some of the
core of the other (long) mail in the heat of the moment. -EE]

Cheers,
-Peter

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901030252.KAA06791>