fcntl/socket anomaly

[Chris Torek]

>In article <10763 at encore.Encore.COM> peralta at encore.com (Rick Peralta) writes:
>>Why when setting the F_SETOWN on a socket a pfind is not done on the PID?
>>Maybe more to the point, why the double standard on how a pgrp is specified?

4.3-tahoe does a pfind, but not for pgroups (negative values), only for
pids (positive values), and only when translating to TIOCSPGRP (more
below).

In article <129970 at sun.Eng.Sun.COM> lm at snafu.Sun.COM (Larry McVoy) writes:
>F_SETOWN has been a botch from day one as far as I'm concerned.  For
>those who don't know (or don't remember) F_SETOWN is used to say "send
>this pid the SIGIO when the time is right".  The documentation has
>always said that you can specify pgrps instead of pids (one of them was
>negative to indicate the type) and SunOS, at least, never did that
>(stay tuned).

Actually, I am fairly sure that SunOS 3.x had the 4.2BSD bug where pid
and pgroup were reversed (between documentation and code).  Whether that
has been fixed, I do not know.  (The SunOS 4.x code is substantially
different, and I have not read it.)

>Furthermore, the F_SETOWN uses the same field in the tty
>structure that the tty sub system uses for job control (where ^Z and
>others get sent).  So if you use F_SETOWN on an active tty you get very
>strange things happening.

(The following applies only to 4.3BSD and otherwise-unchanged derivatives
thereof.)

F_SETOWN on an inode translates into a TIOCSPGRP ioctl, so that whatever
checks are applied to TIOCSPGRP are applied to fcntl(ttyf, F_SETOWN).
The translation goes like this:

	if (value > 0) {		[value is a pid, not a pgroup]
		struct proc *p = pfind(value);
		if (p == 0)
			return (ESRCH);
		value = p->p_pgrp;
	} else				[value is a negated pgroup ID]
		value = -value;
	return (fioctl(fp, (int)TIOCSPGRP, (caddr_t)&value);

For a socket, it sets ((struct socket *)fp->f_data)->so_pgrp to the
given value.  Tty pgroups are stored in tp->t_pgrp: a different place.

>My guess is that the SIGIO interface was a hack that some grad student
>needed.

Not really.  It does seem to be done rather badly, however.

>They hacked it in, it works in the obvious cases, it's stuck
>around.  It needs a rewack to be clean (I just checked SunOS - we do
>absolutely no permissions checks on F_SETOWN on sockets).

They are unnecessary.   SIGIO is a completely benign signal.  If a
process is not catching it, SIGIO is discarded.  If a process *is*
catching it, that process is required to figure out why the SIGIO occurred
and whether it still has any reason to do anything about it, so extra
SIGIO signals merely reduce efficiency.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris