fcntl/socket anomaly

[Larry McVoy]

In article <21691 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>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);

Those checks are inappropriate for the F_SETOWN.  For example, POSIX
insists that the tty in question be your controlling tty.  That's both
unecessary and unlikely for processes wanting SIGIO on a tty.

>>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.

Permission checks are rarely "unnecessary", it's much more likely that
they're either missing or incorrect.  In this case, they're missing.
Suppose I have process A and process B.  A does a F_SETOWN on some
socket and then goes on, expecting a SIGIO at some later time.  B comes
along, and also does a F_SETOWN on the same socket.  A has been
robbed.

To head off a needless discussion: yes, I realize that if you do the
"right thing" everything is OK and there is no need for permission
checks.  My claim is that the number of programmers who "do the right
thing" (sorry spike) are getting fewer and fewer.
---
What I say is my opinion.  I am not paid to speak for Sun, I'm paid to hack.

Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm at sun.com