[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: possible new debconf interface



On Tue, 29 May 2001, Joey Hess wrote:

> [2] The one longstanding gripe about use of debconf in postinst that this
>     does _not_ address is the way a postinst that starts an ill-behaved
>     daemon that does not close all low numbered fd's can appear to lock up.
>     Tough. daemon(3) exists for a reason.

Doing things over a separate file descriptor, is actually worse, if programs
assume that daemon(3) does everything for them.

--
:/tmp/daemon.c
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main( int argc, char **argv )
{
        int fd = open( "/tmp/foo", O_WRONLY | O_CREAT );
        daemon( 0, 0 );
        return 0;
}
yakko:/usr/share# strace -ff /tmp/daemon  3</etc/passwd
...
open("/tmp/foo", O_WRONLY|O_CREAT, 01001102031) = 4
fork()                                  = 16082
[pid 16082] setsid()                    = 16082
[pid 16082] chdir("/")                  = 0
[pid 16082] open("/dev/null", O_RDWR)   = 5
[pid 16082] fstat64(5, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) =
0
[pid 16082] dup2(5, 0)                  = 0
[pid 16082] dup2(5, 1)                  = 1
[pid 16082] dup2(5, 2)                  = 2
[pid 16082] close(5)                    = 0
[pid 16082] _exit(0)                    = ?
--- SIGCHLD (Child exited) ---
_exit(0)                                = ?

Note how neither fd3, which was inheriated, nor fd4(which was opened by the
program), is touched by daemon(3).  fd4 not being touched I would not consider
a bug, as it was open locally.  However, the daemon would need to close all
other descriptors, without closing ones it opened itself.  This is not
straight forward code.

How about, instead of having debconf use an always open descriptor, it uses a
named pipe, and opens and closes when it needs to?  That seems like a
similiarly small enough change to the library, and, as a bonus, fixes this
descriptor inheritance problem.  Just populate the aformentioned DEBCONF_PIPE
environment variable with the name of the pipe.




Reply to: