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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
