Adam Olsen <[EMAIL PROTECTED]> writes:
> The basic idea here is to allow some users to have root access (killing
> processes, accessing files) to a specified set of users, but obviously
> not giving them complete root priveliges.
Root privileges is probably the wrong word here. What you are talking
about is introducing some kind of user hierachy, where each user has a
"parent user". The user mechanism in lyskom (a conference system)
works like that. Each user has an "organizer". Of you are logged in as
a user, you have power over the any user for which you are organizer.
> Implimentation:
> - beyond adding and deleting users, I think all you'd need to modify is
> the auth server, making it check the users root user, then that users
> root user, on up until we either hit the full root (uid 0) or find that
> the user has access. Otoh my knowledge of Hurd internals is quite
> limited.
Hmm. To me, it seems that a natural way to do this would be as
follows:
I start my own auth-server, which runs as me, with all my privileges.
Then I start the untrusted script in such away that it has no
privileges at all with the standard authserver (i.e. like the system's
no-uid" user). However, it could talk to my auth-server, which could
proxy some requests to the real auth server, and in that way delegate
some of my privileges.
In order to let the "sub-user" access files, I could either let it act
as the "no-uid" user, and grant permissions to that. Or I could start
my own filesystem server, and let it talk to my own auth-server.
Is this doable in the Hurd architecture, or am I completely off? I
think the crucial part here is how to locate the authserver and how to
talk to it.
/Niels
