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

[Oystein Viggen <oysteivi@tihlde.org>]

Quoth Niels Möller: 

> Well, it could refuse to create any files by default.

This is the boring solution, but perhaps as good as any.

> And then have some mechanism for making exceptions to this rule. An
> example of such a mechanism (which I don't know if it makes sense): If
> the directory is writable by no-user processes, and if it has the
> setuid bit set, then the no-user process can create files, and the
> created files get the same owner as the directory.

Would this actually make any difference compared do what we have today?
Anybody would still be able to write to the directory by doing an
rmauth, potentially filling up the partition or altering data.

I would say that since login groups are non-persistant, you should never
give the no-user write access to anything more important than /tmp/ on
the disk, as this is effectively the same as giving the same access for
"other"  

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

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.  On the
other hand, there is the possibility that it would help security if one
wrote applications to do "difficult" stuff (like parsing) in no-user
processes, sending the results back through pipes or socketpairs opened
before the fork().

Oystein
-- 
When in doubt: Recompile.