This is the mail archive of the
mailing list for the glibc project.
[Bug libc/19144] daemon() fails to prevent reacquisition of controlling terminal
- From: "mtk.manpages at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 04 Dec 2015 19:29:35 +0000
- Subject: [Bug libc/19144] daemon() fails to prevent reacquisition of controlling terminal
- Auto-submitted: auto-generated
- References: <bug-19144-131 at http dot sourceware dot org/bugzilla/>
--- Comment #2 from Michael Kerrisk <mtk.manpages at gmail dot com> ---
(In reply to Florian Weimer from comment #1)
> How risky is adding the second fork? Would it otherwise change behavior?
* It would fix the bug that allows the caller to reacquire a controlling
terminal. It seems unlikely that any program would depend on that bug in order
to acquire a controlling tty.
* In a properly constructed System-V type daemon, the resulting process is
neither a session leader (which is the critical point) nor a process group
leader. This means (getpid() != getsid() && getpid() != getpgrp()). But with
the baemon(3) in glibc, the following is true for the resulting process:
(getpid() == getsid() && getpid() == getpgrp()). It seems rather unlikely that
any program would depend on this fact though.
> 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.
I changed "calling process's" to "processes".
You are receiving this mail because:
You are on the CC list for the bug.