From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123597 invoked by alias); 16 Oct 2015 19:23:43 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 123523 invoked by uid 48); 16 Oct 2015 19:23:39 -0000 From: "mtk.manpages at gmail dot com" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.23 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mtk.manpages at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-10/txt/msg00233.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D19144 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=3D8726&action=3Dedit Test program for daemon.c The glibc daemon() function has been taking from BSD, but Linux follows Sys= tem V semantics w.r.t. a session acquiring a controlling. The upshot is that af= ter 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=E2=80= =90 low System V semantics (e.g., Linux), this means that if the daemon opens a terminal that is not already a controlling ter=E2=80= =90 minal for another session, then that terminal will inadver=E2=80= =90 tently become the controlling terminal for the daemon. That text highlights the required fix, which is the addition of the followi= ng step after the call to setsid(): if (fork()) exit(0); I have tested the current daemon implementation, and the caller of daemon c= an indeed reacquire terminal, as shown in the following run: $ alias dps=3D'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. --=20 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: 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: List-Subscribe: List-Post: List-Help: , 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" 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: In-Reply-To: References: 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=12926 Florian Weimer 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 --- 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=134572386125610 -- You are receiving this mail because: You are on the CC list for the bug.