Re: password (& host?) file lookups, daemons and stray descriptors

From: Barry Margolin (barmar_at_alum.mit.edu)
Date: 06/24/05 

Date: Fri, 24 Jun 2005 01:20:08 -0400

In article <42bb3ac4$0$5702$9a6e19ea@news.newshosting.com>,
 "Mr. Uh Clem" <uhclem@DutchElmSt.invalid> wrote:

> I've run into a strange problem on an HP11i system involving
> a daemon program which
>
> * calls getpwuid() as part of a security check during
> initialization
>
> * does the normal daemonization things:
> forks, setsid, etc.,
> close all descriptors,
> redirect 0-2 to /dev/null.
>
> * opens a lockfile and does a lockf on it.
>
> * subsequently calls getpwnam() to obtain a uid.
>
> On this system, the getpwnam() call causes the
> lock to be lost on the lockfile. (We don't seem
> to have this problem on our various other *ix
> flavors, although that could be a matter of
> system configuration: nsswitch.conf, etc.)
>
>
> Debugging shows that getpwuid leaves a descriptor
> open after it is called. From truss, it looks as
> if it creates a socket and leaves it open on fd 3.
> It is not hard to believe that Bad Things Happen(tm)
> when the daemonizing closes all child fds and the
> lockfile winds up with file descriptor 3. Truss
> seems to show the getpwnam() call atempting a sendto()
> on fd 3, failing, then doing it's thing on 4 and
> closing 4.

I think the solution is obvious: don't close all file descriptors, just
redirect 0-2 to /dev/null. You shouldn't close random descriptors
because you have no idea whether they're still in use by some library
routines. You have to assume that if a descriptor was left open, it was
for a reason.

What you may want to do is set the close-on-exec flag on all the
descriptors, if your daemon execs other programs. 

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Relevant Pages

  • Re: password (& host?) file lookups, daemons and stray descriptors
    ... > * calls getpwuid() as part of a security check during ... > * opens a lockfile and does a lockf on it. ... I think the solution is obvious: don't close all file descriptors, ... if your daemon execs other programs. ...
    (comp.unix.programmer)
  • process file descriptor limit handling
    ... The current kernel have a problem ... The programs opens descriptors up to ... The open call should fail. ...
    (Linux-Kernel)
  • [RFC] utterly bogus userland API in infinibad
    ... leaks, it does a number of calls of ib_uverbs_event_init. ... to that file - for anybody else descriptors obviously will not make any ... BTW, due to the way we do opens, if another thread sharing descriptor ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • For the almost 4-year anniversary: O_CLOEXEC again
    ... opens the directory using open. ... decides whether newly allocated descriptors are CLOEXEC until further ... I sincerely hope that this is not again answered with curses on POSIX ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)
  • Re: password (& host?) file lookups, daemons and stray descriptors
    ... > I think the solution is obvious: don't close all file descriptors, ... seen on how to do a daemon. ... I've never seen any cautionary text regarding fds from ... called routines which must be handled with care: ...
    (comp.sys.hp.hpux)