public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "mtk.manpages at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/19144] New: daemon() fails to prevent reacquisition of controlling terminal
Date: Fri, 16 Oct 2015 19:23:00 -0000 [thread overview]
Message-ID: <bug-19144-131@http.sourceware.org/bugzilla/> (raw)
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.
next reply other threads:[~2015-10-16 19:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-16 19:23 mtk.manpages at gmail dot com [this message]
2015-10-19 8:36 ` [Bug libc/19144] " fweimer at redhat dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-19144-131@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=glibc-bugs@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).