Re: Larger dev_t

[Albert D. Cahalan]

Andrew Pimlott writes:
> On Tue, Mar 27, 2001 at 02:13:47PM -0800, H. Peter Anvin wrote:

>> The problems with devfs (other than kernel memory bloat, which is pretty
>> much guaranteed to be much worse than the bloat a larger dev_t would
>> entail) is that it needs complex auxilliary mechanisms to make
>> "chmod /dev/foo" work as expected (the change to /dev/foo is to be
>> permanent, without having to edit some silly config file)
>
> The elegant solution seems obvious to me.  What we have today is two
> namespaces--device major/minor, and filesystem--that are bridged by
> special files.  Special files live in the filesystem namespace and
> point into the major/minor namespace.  Objects in the major/minor
> namespace are directly accessible only by root (ie, only root can
> mknod(2)); but when accessed through special files, access control
> comes from the special file.
> 
> The concept that makes this work is that the special file is a
> "pointer with permissions".  To make devfs work, you want the same
> thing--except a pointer into filesystem space, not major/minor
> space.  Unix doesn't have this, but it would be a simple cross of
> symlinks (pointer living in the filesystem and pointing into the
> filesystem) and special files (pointers with permissions).
> 
> To be concrete:  You'd have a root-only (or perhaps the directories
> could be a+rx--but minimal policy) hierarchy under /devices, and the
> admin would populate /dev with "special symlinks" that point into
> /devices, and give the appropriate permissions to users.

This can be done with an lchmod() and support for setuid symlinks.

Read     can see where the link points
Write    ignored, or XOR the on-disk data with 0222 and...?
Execute  can follow the link
Setuid   link followed as for the owner
Setgid   link followed as for the owner's group
Sticky   reserved for future use

Then you get:

lr-sr-xr-x 1 root root 17 Mar 21 2000 /dev/null -> /devices/mem/null