Re: start-stop-daemon?
Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 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.
setlogin and getlogin are a BSD-ism which we implement. setlogin, at
least, is now used to separate the sandboxes for different nousers,
which became the case after the "this is deprecated" comment. At
least the comment on setlogin should be removed.
The habit I once had of writing snide comments like "you are not
expected to understand this" mostly came from a very famous example of
such in the Version 6 source code for Unix, and should be confined to
internals of the system and not header files; certainly not
documentation.
> 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).
That's a reasonable way. The use of setlogin as the marker makes a
common-ancestor model work for nouser tasks all being run from the
same shell, when we noticed that this would be necessary.
However, I become reluctant to go too far in this direction. At some
point, all you're really doing is allowing anonymous users to create
new user ids when they want. If that's a useful feature, then let's
add it directly.
> 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]
Yeah, I can see this as useful.
Reply to: