[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: unowned processes and who controls them (was: Re: passwd entry for uid -1



On Thu, Jun 07, 2001 at 02:04:43PM +0200, Oystein Viggen wrote:
> > > Unless you pre-open this directory, how can you reliably make sure that
> > > a program/daemon running as no-user gets access to the same files the
> > > next time you start it?  Let's say BIND is started in the system boot
> > > scripts, and I later log in through telnet and restart BIND (kill and
> > > start again), how would you make sure BIND gets the same files.
> > 
> > All processes in the same login group should get access to the same files.
> 
> If I log in as root on the console, through telnet, and through ssh and
> noauth the three, would these be in the same login group?  In my tests,
> it seemed that one rmauthed oysteivi logged in through telnet could not
> kill the processes of another rmauthed oysteivi. (two nousers with
> different login ids, no?)

Right.  You have to decide if you want isolation or control.  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.

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.

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).

> 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?

> Wouldn't
> you have to preallocate a login id for bind then, effectively doing the
> same as having a dedicated named user?

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.

> (I'm not asking to be difficult, I just want to make sure that both I
> and everybody else who is interested understands this and its
> implications  :)

I am only surprised that you seem to flip flap between isolation and
control.  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.
 
> > Of course.  I also should have mentioned data protection etc.
> 
> Perhaps, but would you normally give other read access to sensitive
> data? 

I really am not interested in defending the fourth flag set, as I don't use it
at all.  But as I started it, here it comes: you might have only trusted
users on your system, and have a message board where you announce that you
leave home for a trip to south africa for four weeks.

Or you might want to share your mp3 collection with all users on the system,
but not with anybody outside.

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 ;)

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



Reply to: