Re: unowned processes and who controls them (was: Re: passwd entry for uid -1
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?
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 ;)
> 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.
Even more importantly, how can you do the above _without_ letting just
any user rmauth and get at the same files?
> 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?
> 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?
> It's certainly not a straightforward replacement right now, but with some
> additional interfaces and servers to manage such nousers, it might be viable
> in ths future.
Agreed. It _might_.
Oystein
--
ssh -c rot13 otherhost
Reply to: