Re: config(5) break down

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> Could this be resolved by adding a "get label" ioctl that could be
>>> used on any device?
>> That's part of the plan of "my devfs".
> yuck.

Agreed.  For one thing, you can't ioctl anything until you open it,
which is a nontrivial operation for many devices - and closing it when
you're done is a nontrivial operation for even more devices.

> One of the nice things about having symlinks, instead of requiring a
> new ioctl, is that you don't need any special tool to see how things
> are connected together: you can just use ls.

I just had a thought.

When symlink mode bits went in, I thought about possible meanings for
the set-id bits; I think they are a solution that has just found its
problem.

The principal (only, as far as I can see) reason why the "symlink into
a devfs tree" paradigm isn't good is that it breaks permissions: the
devfs nodes' permissions will either allow access they shouldn't or
deny access they shouldn't, with no way for the symlinks to fix it.

But if the set-ID bit on a symlink means that the symlink's owner is
used for the access to the linked-to thing, then all devfs nodes can be
owner root mode 600 and user-visible device nodes can be setuid-root
symlinks.  Then the permissions on the symlink control access.

I'm not sure I like it - I think it makes more sense to have the set-ID
bit control the rest of the path walk rather than access to the thing
at the end of that walk - but that can be dealt with either of two
ways: either devfs mounts are mode 700 directories containing mode 666
devices, or the set-ID bit *does* control the path walk - but the
sticky bit, if set, says it also controls the access at the end of it.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B