>> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/