public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/19144] New: daemon() fails to prevent reacquisition of controlling terminal
@ 2015-10-16 19:23 mtk.manpages at gmail dot com
  2015-10-19  8:36 ` [Bug libc/19144] " fweimer at redhat dot com
  0 siblings, 1 reply; 2+ messages in thread
From: mtk.manpages at gmail dot com @ 2015-10-16 19:23 UTC (permalink / raw)
  To: glibc-bugs

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.
>From glibc-bugs-return-30197-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Oct 16 20:35:38 2015
Return-Path: <glibc-bugs-return-30197-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 122818 invoked by alias); 16 Oct 2015 20:35:38 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 122736 invoked by uid 48); 16 Oct 2015 20:35:34 -0000
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/12926] getaddrinfo()/make_request() may spin forever
Date: Fri, 16 Oct 2015 20:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: network
X-Bugzilla-Version: 2.13
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: fweimer at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status cc assigned_to
Message-ID: <bug-12926-131-FZ5f9kkRo0@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-12926-131@http.sourceware.org/bugzilla/>
References: <bug-12926-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-10/txt/msg00234.txt.bz2
Content-length: 1000

https://sourceware.org/bugzilla/show_bug.cgi?id\x12926

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED
                 CC|                            |fweimer at redhat dot com
           Assignee|drepper.fsp at gmail dot com       |fweimer at redhat dot com

--- Comment #9 from Florian Weimer <fweimer at redhat dot com> ---
There are several other places which use < 0 instead of <= 0, so commit
fda389c8f0311dd5786be91a7b54b9f935fcafa1 may be incomplete.  I will also get
clarification if netlink responses from the kernel can get lost.

We might also simplify the netlink processing logic a bit because kernel
messages can no longer be spoofed due to this kernel fix:

http://marc.info/?l=linux-netdev&m\x134572386125610

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


^ permalink raw reply	[flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-10-19  8:36 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-16 19:23 [Bug libc/19144] New: daemon() fails to prevent reacquisition of controlling terminal mtk.manpages at gmail dot com
2015-10-19  8:36 ` [Bug libc/19144] " fweimer at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).