Re: unowned processes and who controls them (was: Re: passwd entry for uid -1
On Thu, Jun 07, 2001 at 09:08:49AM +0200, Oystein Viggen wrote:
> Quoth Marcus Brinkmann:
>
> > Let's not give up so fast ;) A special translator could provide a
> > filesystem that provides seperate name spaces for different login groups.
> > I think it requires a new interface in proc to reliably compare login groups
> > of processes (the string is not reliable!).
>
> The login group id is a string? Semi-random?
Internally to proc, it is ia string pointer. This is what proc uses for
comparison. However, for getlogin() the string is dup'ed.
All users of the login shell are in login groups named "login", but they are
all distinct to proc.
> Wouldn't it be just as easy to have it as an int or something and be
> happy with the 2^32 potential login ids it would give us? I don't
> think you will even be running 2^32 processes on ia32 on hurd anytime
> soon ;)
I am not sure this login group stuff as it is is really meant to be used to
make the distinctions we are trying to make. As I said, the comment in
process.defs seems to indicate it is an interface one should not use. Maybe
ask Thomas. A string is used because this is what getlogin() returns.
> > The proxy server could simply use subdirectories in /tmp to store the
> > data, and store additional information about it in core or metadata files.
> > The nouser would need to go through this servers filesystem to access its
> > data (the real data is owned by root and not visible by anyone else).
>
> 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.
> Even more importantly, how can you do the above _without_ letting just
> any user rmauth and get at the same files?
As long as they are in different login groups, all will be fine.
> > If you want all your users to run a certain application, but not nousers,
> > you can set the fourth bit set to 0 and activate it.
>
> I guess this would help against somebody gaining nouser access through a
> service running as nouser, but unless this particular app needs to be
> setuid, I think you'll have problems stopping even a nouser from just
> downloading the same app from elsewhere?
Of course. I also should have mentioned data protection etc.
> > Note that we have a login shell which runs with no uids/gids.
>
> How does that work? When I type login root, I am running a setuid root
> /bin/login?
The login program runs as root, but the shell it spawns runs in a different
login group ("login") and without any uids/gids.
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: