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

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

[mtk.manpages at gmail dot com]

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.

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

[fweimer at redhat dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4785 bytes --]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
How risky is adding the second fork?  Would it otherwise change behavior?

By the way, the manual daemon(3) manual page talks about the “calling process's
current working directory”.  I think this is misleading because the function
exits the calling process before changing the current directory.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-30217-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Oct 19 09:51:20 2015
Return-Path: <glibc-bugs-return-30217-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 17137 invoked by alias); 19 Oct 2015 09:51:20 -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 17057 invoked by uid 55); 19 Oct 2015 09:51:16 -0000
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/18032] buffer overflow (read past end of buffer) in internal_fnmatch
Date: Mon, 19 Oct 2015 09:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.21
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: 2.22
X-Bugzilla-Flags: security+
X-Bugzilla-Changed-Fields:
Message-ID: <bug-18032-131-JpR4oaMeMo@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-18032-131@http.sourceware.org/bugzilla/>
References: <bug-18032-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/msg00254.txt.bz2
Content-length: 1974

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

--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, release/2.19/master has been updated
       via  012adb33827608d3b78e3832a1948b468b549946 (commit)
       via  fc843f6e48737d3d6690c5cf355d9719274efee1 (commit)
      from  3fd498242948b1fa944c56646ec9b156387dd310 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h\x012adb33827608d3b78e3832a1948b468b549946

commit 012adb33827608d3b78e3832a1948b468b549946
Author: Paul Pluzhnikov <ppluzhnikov@google.com>
Date:   Sun Feb 22 12:01:47 2015 -0800

    Fix BZ #17269 -- _IO_wstr_overflow integer overflow

    (cherry picked from commit bdf1ff052a8e23d637f2c838fa5642d78fcedc33)

    Conflicts:
        ChangeLog
        NEWS

https://sourceware.org/git/gitweb.cgi?p=glibc.git;hü843f6e48737d3d6690c5cf355d9719274efee1

commit fc843f6e48737d3d6690c5cf355d9719274efee1
Author: Andreas Schwab <schwab@suse.de>
Date:   Thu Feb 26 14:55:24 2015 +0100

    Fix read past end of pattern in fnmatch (bug 18032)

    (cherry picked from commit 4a28f4d55a6cc33474c0792fe93b5942d81bf185)

    Conflicts:
        ChangeLog
        NEWS

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog            |   12 ++++++++++++
 NEWS                 |    2 +-
 libio/wstrops.c      |    8 +++++++-
 posix/fnmatch_loop.c |    5 ++---
 4 files changed, 22 insertions(+), 5 deletions(-)

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