Re: start-stop-daemon?
On Mon, Nov 12, 2001 at 09:48:17AM -0800, Jeff Bailey wrote:
> Has the start-stop-daemon been hacked so that it can start servers
> with no privs yet? If not, that might be a cool project for someone
> looking to enhance an important app.
Running a unix daemon as no user is not trivial. Neal and me spend some time
thinking over the issues of who controls which processes, and in general it
is quite involved (I think there were four different cases to consider, I
still have the tissue of the train restaurant on which we recorded our results).
Also, it requires special support in the server itself; like with suid, it needs
to allocate some resources and then drop the user ids.
One keyword is "login collection". Below I include a draft from a mail I
started to write some time ago, but note that it is out of date. I remember
that I found some aspect of the code I did not considered yet which does
what I suggest in the draft at least partially, so I decided to not send it
before considering more about it.
Note that this is probably a matter for bug-hurd.
Thanks,
Marcus
Some OLD mail draft:
I see that proc_setlogin and proc_getlogin are deprecated, process.defs says
they are there "for historic reasons" only, and I am "not expected to
understand this". Nevertheless, they are implemented as setlogin() and
getlogin() in the C library, and they are used in one important case:
To isolate different nousers, while making it possible for each nouser to
control processes he fork()/exec()ed.
Neal and me actually plan to extend the feature. We feel that a user should
be able to control tasks running without user ids from anywhere within the
system (say, from another terminal). Thus we want to associate an owner
with each login collection, which is inherited by childs. The owner is
then allowed to send signals to those processes (without user ids).
Also, we want a parent-child relationship between login groups, as this
allows a nouser to create new login groups (to isolate them from each
other), while still holding control over them. The owner is here "root" for
all login groups (inherited from init), so the above extension doesn't work
for this case. (While this extension alone doesn't help in the above case,
where the user logs in from another terminal and wants to have control). [1]
We don't think this is stretching the nouser concept, as we want to exploit
it by running more tasks without user ids. (Neal pointed out that it might
be possible to run the auth server without user ids!). For this, we need to
make it more useful. Currently, you loose control over new login groups
without user ids (only root can send signals).
[1] The last case, that a nouser wants to get control over login groups from
another nouser session (say, the same nouser connects a second time), can be
implemented by an authorization proxy server in user space by this nouser.
This is more effort, but it's really a remote border case in the first
place.
--
`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: