[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 Wed, Jun 06, 2001 at 11:22:38PM +0200, Oystein Viggen wrote:
> (you cannot give access for "the bind process running as no-user",
> "the no-user that was previously root", or "the no-user with this login
> group ID" and since anybody can go no-user, no-user access is world
> access).
>
> Thinking more about this, I can't see any secure way you could let a
> no-user process store data to be retrieved on restarting the process,
> except opening the files before going no-user.

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

You could even implement a quota system in this proxy server (although this
is probably better left for yet another server).

> I also see very little
> reason for the fourth set of permissions in the filesystem, as this is
> in most cases the same as "other" (exception is when other has more
> access than group, and your user are in the group).

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.  Note that we have a
login shell which runs with no uids/gids.

> IOW, apache running its threads as no-user would be OK, a read-only,
> passive only anonymous ftp server could run as no-user, but in many
> (most?) cases, this can not replace running as a dedicated user.

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.

-- 
`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: