Re: password (& host?) file lookups, daemons and stray descriptors
From: Barry Margolin (barmar_at_alum.mit.edu)
Date: 06/25/05
- Previous message: Ulrich.Teichert_at_gmx.de: "Re: Why I could not catch the signals on HP_UX?"
- In reply to: Mr. Uh Clem: "Re: password (& host?) file lookups, daemons and stray descriptors"
- Next in thread: Mr. Uh Clem: "Re: password (& host?) file lookups, daemons and stray descriptors"
- Reply: Mr. Uh Clem: "Re: password (& host?) file lookups, daemons and stray descriptors"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 24 Jun 2005 23:52:28 -0400
In article <42bc1ccc$0$5791$9a6e19ea@news.newshosting.com>,
"Mr. Uh Clem" <uhclem@DutchElmSt.invalid> wrote:
> Yeah, I guess so, but this is contrary to all I've ever
> seen on how to do a daemon. Consider these early hits
> from Googling for [unix daemon process] :
>
> http://www.enderunix.org/docs/eng/daemon.php
> http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC16
> http://www.unix.com/archive/index.php/t-3736.html
>
> I've never seen any cautionary text regarding fds from
> called routines which must be handled with care:
I think everyone may assume that you do this so early in your program
that nothing would have already opened fd's. Notice that the first page
you referenced above refers to these as "inherited" fd's -- the
expectation is that any fd's that are open were inherited from the
calling process, not opened by this process. But when you call library
routines, and they may have opened descriptors and stored them in static
variables, this assumption is no longer valid.
> I'm also rather surprised that the man pages for
> routines such as getpwuid() are silent on their
> creation of fds and the handling required. (And
These fd's are internal implementation details, and the caller is not
expected to "handle" them. They might change from release to release,
and programs should not depend on them.
> I still don't see anything in the truss which
> explains the lost lock.) I'm also surprised
> it is not possible to properly close such open
> fds, with routines such as endpwent().
Since it's a network socket, I think it's probably part of the NIS
library, not anything specific to password lookup. Endpwent() doesn't
have any way to make NIS discard the socket it uses to talk to the
server.
>
> > What you may want to do is set the close-on-exec flag on all the
> > descriptors, if your daemon execs other programs.
>
> So generic daemonizing might be something like:
>
> - close all fds above 2 at the start of main (?)
Right. Then you can call getpwuid() to perform your validity check.
Since stderr is still pointing to its original location, you can report
an error.
>
> - fork; setsid; fork; chdir("/" or other safe place);
> close 0-2 and redirect (typically to /dev/null);
> set close-on-exec for fds above 2
Seems right to me.
-- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me ***
- Previous message: Ulrich.Teichert_at_gmx.de: "Re: Why I could not catch the signals on HP_UX?"
- In reply to: Mr. Uh Clem: "Re: password (& host?) file lookups, daemons and stray descriptors"
- Next in thread: Mr. Uh Clem: "Re: password (& host?) file lookups, daemons and stray descriptors"
- Reply: Mr. Uh Clem: "Re: password (& host?) file lookups, daemons and stray descriptors"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
