[Bug libc/19144] New: daemon() fails to prevent reacquisition of controlling terminal

["mtk.manpages at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19144

            Bug ID: 19144
           Summary: daemon() fails to prevent reacquisition of controlling
                    terminal
           Product: glibc
           Version: 2.23
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: mtk.manpages at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 8726
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8726&action=edit
Test program for daemon.c

The glibc daemon() function has been taking from BSD, but Linux follows System
V semantics w.r.t. a session acquiring a controlling. The upshot is that after
calling a daemon() the process may inadvertently acquire a controlling
terminal. I just added the following text to the daemon(3) manual page:

       The GNU C library implementation of  this  function  was  taken
       from  BSD, and does not employ the double-fork technique (i.e.,
       fork(2), setsid(2), fork(2)) that is necessary to  ensure  that
       the resulting daemon process is not a session leader.  Instead,
       the resulting daemon is a session leader.  On systems that folâ
       low  System  V  semantics (e.g., Linux), this means that if the
       daemon opens a terminal that is not already a controlling  terâ
       minal  for  another  session,  then that terminal will inadverâ
       tently become the controlling terminal for the daemon.

That text highlights the required fix, which is the addition of the following
step after the call to setsid():

    if (fork())
        exit(0);

I have tested the current daemon implementation, and the caller of daemon can
indeed reacquire terminal, as shown in the following run:

$ alias dps='ps -o "pid ppid pgrp sid tty cmd" -C dtest'
$ sudo ./dtest /dev/tty5
hello
$ dps; sleep 10; dps
  PID  PPID  PGRP   SID TT       CMD
11084     1 11084 11084 ?        ./dtest /dev/tty5
  PID  PPID  PGRP   SID TT       CMD
11084     1 11084 11084 tty5     ./dtest /dev/tty5

Note that in the final line we can see that tty5 has become the controlling tty
of the process.

-- 
You are receiving this mail because:
You are on the CC list for the bug.