Re: unowned processes and who controls them (was: Re: passwd entry for uid -1
Quoth Marcus Brinkmann:
> Right. You have to decide if you want isolation or control.
Actually, I want both to the biggest possible degree ;)
> A few mails ago, you wondered if one nouser could gain control over
> other nousers, and the answer is if and only if they are in the same
> login group.
Yep. And each login gets a "new" (or at least not currently used) login
group, right?
> If you want to gain control, then it should be straightforward to add an
> interface to proc that sets the logingroup of one process to that of
> another. This can be used by root to get access to another login group.
> However, for obvious reasons, this is root-only. After someone drops the
> uids, you have no idea anymore who owns this task, so you can not perform
> any authentication to let others (except root) in the same login group.
Agreed. Such a feature could probably be nice for something, too,
although I'm not quite sure what.
> If you need to do more fancy stuff, you will have to start other tasks in
> the same login group that allow you to control what happens there (for
> example a bind wrapper that takes care of restarting it on request).
Perhaps a possibility. Not pretty, though.
> > If not, when you log in, start bind, log out, log in, stop bind, start
> > bind, how can you make sure it gets access to the same files?
>
> You can't have your cake and eat it, too. Isn't this the saying?
My knowledge of English idioms is, alas, quite limited.
Anyway, what I describe for bind would work as noser and your special
logingroup file system if we make sure that the init script takes care
of storing the files somewhere else when stopping the process and
restoring it when starting (perhaps somehow using the
set-your-logingroup interface you describe earlier in this mail).
The logingroup file system will also need to remove files when the last
process with the owner group exits to prevent information leakage when
the login group is recycled for a new process.
> If you want to do it the way you described, yes. You really have to decide
> what you want to do. If you want to do it the Unix way, then do so. If you
> want to do it the Hurd way, do that.
Before I decide what I want to do, I want to find out what can be done.
If the Hurd way is safe and useful while providing advantages over the
Unix way, I would of course want to use the Hurd way. Currently, my
knowledge of Unix (esp. Linux) is much bigger than my knowledge of Hurd
and this of course affects my reasoning.
> I am only surprised that you seem to flip flap between isolation and
> control.
Are these goals necessarily conflicting? Having nouser processes with
different login groups isolated like now, while allowing root to frob
login groups at will would achieve a good level of both, I think.
> When you drop the uids to become anonymous and isolate yourself from
> the Unix world in the Hurd, you can not expect to do Unix things to
> cross the border in either direction. You will have to do Hurd things
> to get across that.
Perhaps not. I would like for Hurd specific enhancements to be to a
certain extent Unix _like_, so that it would be easier to port Unix
programs to using the Hurd extensions, though. The less you have to
rewrite Unix programs to make them work The Hurd Way, the better, I
think. (And after all, we all know that "The GNU Project was launched
in 1984 to develop a complete Unix-like operating system[...] ;)
Of course, since we can run Unix programs in a Unix like environment on
the Hurd without using the special Hurdish features, this is not a very
big deal. Perhaps it would be just as well to make people do some
rewriting to use the advanced features of the Hurd. Saves a lot of
cruft in the Hurd itself.
> With regards to the fourth set of permissions, it all boils down to that:
> They are there for you to use. Take it or leave it ;)
Point taken :)
Oystein
--
When in doubt: Recompile.
Reply to: