Date: Sun, 12 Jan 1997 02:26:00 +0000 From: davidn@unique.usn.blaze.net.au (David Nugent) To: bde@zeta.org.au (Bruce Evans) Cc: joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG Subject: Re: DEVFS permissions &c. Message-ID: <Mutt.19970112022600.davidn@labs.blaze.net.au> In-Reply-To: <199701121444.BAA14336@godzilla.zeta.org.au>; from Bruce Evans on Jan 13, 1997 01:44:33 %2B1100 References: <199701121444.BAA14336@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans writes: > >> I've exchanged a couple of thoughts with Bruce about it. Maybe we > >> could teach mtree(8) to help in this step. > > > >Yes, that would certainly be the way to do it. > > Not really. Things it doesn't do right include: > - wildcards. The equivalent of `chmod 666 /dev/tty[pqrs][PQRS]*' is a > huge list. This could be resolved. It will involve expanding mtree's syntax a little (about which I admit to knowing next to nothing :-)), but I believe the basic functionality should be part of mtree, or if not mtree, then something along the same lines. SCO implemented something akin to this with setperms or whatever it was called, and used it to build systems from their install packages, and check permissions/files after installation as well. Of course, they didn't have devfs to contend with, but it did handle device nodes, named pipes and other special files, directory and file ownership and permissions. Expanding on the idea a little might see /dev/security's setuid monitoring replaced with something that checks against a pre-defined list. Yes, large lists, and possibly exploitable targets at that. :-( And I agree that the sheer volume of data and its maintenance may be a problem unless it is somehow maintained and driven by the source tree, and maybe even /usr/bin/install, together with local administrative overrides. Even in the non-devfs case, MAKEDEV itself may potentially be replaced or enhanced by such a tool. Perhaps this discussion may also be related to the "system packages" discussion a few weeks ago. Right now, for example, you can't just "make world" on a system which have specific components replaced - like sendmail -> zmailer/qmail, since /usr/sbin/sendmail will be overwritten (actually, this is the only real reason I don't run zmailer on systems where I keep -current since I far prefer it to sendmail for a number of reasons. Others have different preferences obviously). At this risk of confusing the issue further, there's also the ports/packages system to consider. > - futures. When a new disk with lots of slices and partitions on it > is detected, how is its mode and group changed so that a member of > group operator can access it? I guess this is one case where persistence wins. Once changed, the system shutdown, and when next initialised it will be correct. Defaulting to 0600 0.0 would seem reasonable. What other options are there? > >Seriously, I've used sysv for many years, and grew to quickly despise > >the sysv approach. It does have some good sides, but, for example, > >Sun's tree of symlinks to init/shutdown scripts is definitely an > >overkill. > > I expect a tree of devices would be overkill too. You would need evil > symlinks to reduce /dev/disks/raw/scsi/bus0/id0/lun0/slice2/partitionh > to something like /dev/rsd0h :-). Please, don't remind me again of Solari's /devices and /dev symlink nightmare. I've almost recovered and would hate to suffer a relapse. :) Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19970112022600.davidn>