Kjetil Torgrim Homme wrote:
>>
> Agreed. I think the tar "solution" gives people the wrong idea. A
> backing store may be seen as superior to tar, since it is less error
> prone, but it is not a good solution to the _real_ problem. One of
> the motivations for devfs was to handle hotplug devices without the
> need for a preconfigured /dev. As has been pointed out, a backing
> store _is_ that preconfigured /dev. We have only obsoleted MAKEDEV.
>
> To make devfs really useful the permissions need to be set on a higher
> level, algorithmically and dynamically. That is, a user space device
> manager where you can specify _general_ rules like "members of the
> backup filegroup shall have read access to all storage devices". Or
> "the currently logged in user shall have full access to all removable
> media" -- enumerating the Zip, the floppy, the CDROM etc. shouldn't be
> necessary (but the admin might want to). The pam_console module tries
> to address these issues from the viewpoint "the user changes". The
> truly general solution needs an enhanced devfsd(?) which handles
> hardware changes as well, even devices unforeseen by the sysadmin.
>
> Some work has to be done in the kernel, though -- the drivers need to
> supply enough information for the device manager to classify its
> resources and apply the rule sets.
>
Correct. What I have maintained all along is that this device manager
makes devfs itself unneccessary, except perhaps for a few mostly
gimmicky features (like a symlink to the root device.) It wouldn't
matter if kernel memory was swappable, but it isn't -- for good reason.
On a similar note, I notice that recent versions of RedHat (via GNOME?)
seems to magically change owners on a whole bunch of devices. It seems
to me that it would be a *much* cleaner solution would be to have a
special group for the console owner, and when logging in the user add
that group to his auxilliary group list via setgroups().
Device nodes really scream for ACLs, though.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:22 EST