On Wed, 8 Jan 1997, der Mouse wrote:

> This (which is like my /kern/dev, only calling it /devices instead)
> sounds like an elegant idea, in that it provides a kernel-exported
> interface based on strings instead of small integers.  The major
> problem with it is permissions: either /devices (or /kern/dev, or
> whatever) has to support chmod, chown, etc, and some way has to be
> provided to preserve such changes across reboots, or else /devices has
> to be o-x (to prevent vanilla users from creating their own symlinks to
> it), the symlinks out of /dev have to have mode bits of their own, and
> these same symlinks have to somehow be able to bust through the
> protection on /devices.  Now, I already have code that implements mode
> bits on symlinks (though not doing what'd be wanted here) and have been
> thinking about setuid and setgid symlinks (they change the effective ID
> with which the rest of the path walk is done), but combining them
> doesn't solve this problem because you want them owned by one user (for
> the permissions checking) and you want them setuid to a potentially
> different user (to bull through /devices).

is it a bad thing to change bits in the kernel itself?  I was recommended
recently to go and change things in the kernel file with gdb (set nbuf=128),
and it didn't seem to cause any problems with the running of the system at
the time. 

if this is allowed, then why can't there be a part of the device description
structure that says who owns it and who is allowed to write to it?  any 
changes made to the devfs filesystem mounted on /dev could be written to 
the running kernel by the devfs filesystem?

alternatively, just have a /etc/devtab file that contains this information,
and is updated by the devfs when it changes (I guess this is possible?)
default ownership information has to be stored somewhere, at the moment it is
stored in the /dev/MAKEDEV script.. 

iain