Re: dh_installinit
Manoj Srivastava <srivasta@debian.org> writes:
> I would agree that no entity should be passing open file
> descriptors off to other processes unless this is deliberate, and in
> that case a proper policy has been written for it.
Okay, I think we're in agreement there. The only open question is what a
daemon should do when it's mistakenly and erroneously handed open file
descriptors by its parent process that it's not aware of (other than 0, 1,
and 2, of course). Right now, some daemons close all file descriptors up
to some arbitrary point (255 is common) but leave higher ones open, others
try to get the file descriptor limit via getrlimit and close everything up
to that limit, and others only deal with file descriptors they themselves
opened.
(I certainly agree that any daemon that opens file descriptors needs to
handle them appropriately if it also forks -- and, of course, any daemon
that uses PAM may fork. Usually by setting close-on-exec on all opened
file descriptors.)
>> Insofar as there is any security impact here (which is dubious in most
>> cases),
> Why do you say that? If a process acquires a file handle on a
> privileged file while running as dpkg_t; and passes it to debconf
> running as debconf_t; why is there no security impact? dpkg_t might
> have more access than debconf_t in the policy being run.
Well, I was thinking of the specific case that started this discussion,
which as I understand it was the case of a debconf handle being left open
when starting a daemon. I could be misunderstanding the problem, but if
not, while this is a violation, I have a hard time figuring out what a
process could do with the debconf handle. But that may just be lack of
imagination on my part.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: