Xref: utzoo comp.bugs.sys5:1161 comp.unix.wizards:18679
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ateng!chip
From: chip@ateng.com (Chip Salzenberg)
Newsgroups: comp.bugs.sys5,comp.unix.wizards
Subject: Re: SysVR3.2 Setpgrp behaviour
Message-ID: <253664A4.20995@ateng.com>
Date: 13 Oct 89 22:41:38 GMT
References: <1970@oid.UUCP> <1273@virtech.UUCP>
Organization: A T Engineering, Tampa, FL
Lines: 41

According to cpcahil@virtech.UUCP (Conor P. Cahill):
>The setpgrp() program only places the current program into a different
>process group and disconnects the link from the process to the controlling
>tty.

Quite.

>PS-> you should still do a setpgrp() after the fork to ensure that your 
>new program does not recieve signals from the terminal.

You should also do another fork() AFTER the setpgrp().  Otherwise, the child
process remains a process group leader.  And if a process group leader
without a controlling tty opens a tty that no other process has open at the
time [inhale], then that tty becomes the process's controlling tty.  So the
child must fork() again; then the grandchild process is a safe daemon.

Finally:

	/*
	 * Daemon code.
	 * Insert error checking to taste.
	 */

	if (fork() != 0)
		exit(0);
	setpgrp();
	if (fork() != 0)
		exit(0);

	/*
	 * And away we go...
	 */

Personally, I think this whole "setpgrp does two jobs" is a grody hack.
It's as bad as the "setuid(getuid()) is reversible for all setuid programs
except setuid-root programs" grody hack.  Well, maybe not that bad.
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>
"'Why do we post to Usenet?'  Naturally, the answer is, 'To get a response.'"
                        -- Brad "Flame Me" Templeton