Re: dh_installinit
Petter Reinholdtsen <pere@hungry.com> writes:
> [Russ Allbery]
>> Those file descriptor close loops are somewhat controversial. Not
>> everyone agrees that they're a good idea, and some upstreams will push
>> back on doing it. I find them a bit dubious myself; there are various
>> hacks that, while hacks, come in very handy but are broken by daemons
>> that do this. (Process-inherited Kerberos caches, for example.)
> Oh. I was not aware that some found such feature controversial. Why
> can't these people use environment variables to inherit information
> between processes? It is ment to be inherited also by daemons, and I
> do not believe there is any controversial about that.
Well, to give one example (the Kerberos ticket cache hack), the idea is
that you want somewhat tighter control over what can read the ticket cache
than just per-UID controls. So instead, you store the ticket cache in an
unlinked file with an open file descriptor that's inherited across forks,
and then add the new ticket cache implementation to the Kerberos library
(so the daemon may not be aware it even exists). I think the actual
implementation may do something a bit more complex than an unlinked file.
There's no way to do this with just an environment variable because one
can't put the whole cache in the variable so there's some external object
somewhere that still has to store the cache. (Plus, environment variables
are public.) Without file descriptor inheritance, you have to resort to
things like shared memory segments, which get a lot more annoying.
There are still ways to steal the ticket cache if you have the same UID
but no access to the file descriptor, but it's a lot harder and adds a
moderately useful barrier that has made practical improvements in the
incidence of cache stealing at some sites.
As I say, it's definitely a hack, but this sort of hack is sometimes
useful in various real-world circumstances, at least temporarily. I don't
know of any use of extra file descriptors that I wouldn't call a hack, but
I know of several of these kinds of hacks. (For example, a cheap way of
arranging to be signaled when a daemon exits, even if it puts itself into
a separate process group, is to leave open a high-numbered file descriptor
and then select and wait for EOF on it.)
I guess I lean towards having the system opening the additional file
descriptor be responsible for managing it and controlling its inheritance.
That means closing the debconf file descriptor in init scripts or some
other similar place rather than expecting daemons to be able to handle it,
although I can also definitely see the arguments in favor of daemons
closing file descriptors. (I do think daemons should do something
appropriate with stdin, stdout, and stderr.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: