[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: config(5) break down
>>> 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".
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
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
Main Index |
Thread Index |