Petter Reinholdtsen <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
