Date: Wed, 16 Oct 1996 19:41:42 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, jkh@time.cdrom.com, jehamby@lightside.com, jsigmon@www.hsc.wvu.edu, freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD 2.2.x release question Message-ID: <199610170241.TAA04631@phaeton.artisoft.com> In-Reply-To: <199610170144.LAA09118@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 17, 96 11:14:55 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I thought it was supposed to generate devices dynamically based on > > hardware presence, not persistently based on user fiat. > > The issue with persistence is that not everyone is happy with the > default permissions puked up by the drivers. Our embedded boxes, for > example, want /dev/io 0660, which would be insane for a production > system. > > In essence, the "persistence" for devfs needs to hold : > > - ownership > - permissions > - symlinks > > IMHO, there's nothing there that can't be achieved with a script > argument to mount_devfs, although it could be argued that because the > devfs has to be mounted before the script could be processed there is > a potential window of vulnerability there. Not if you do it before you start the external services, like getty. In any case, you could "fix" the devfs away from the defaults using a tool to manipulate the data portion of the kernel -- assuming you were interested enough in persistance to write the tool. Alternately, you could use union mounts -- assuming you were interested enough in persistance to write the code. Julian should not have to "buy" devfs's way into FreeBSD via appeasement; It didn't work for Walpole in 1939, it won't work for Elisher in 1996. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610170241.TAA04631>