fcntl/socket anomaly

[Larry McVoy]

In article <21710 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>In article <129979 at sun.Eng.Sun.COM> lm at snafu.Sun.COM (Larry McVoy) writes:
>>Those checks [applied by TIOCSPGRP] 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.
>
>Ah: this is different from what you said (or at least, what I understood)
>before.  Now you seem to mean `any process should be allowed to ask for
>SIGIO on any file descriptor to which it can apply an fcntl, and should
>receive SIGIO signals whenever it could read from / write to that descriptor.'

Well, while I agree that this would be nice, it's not at all what I
meant and I think you know it.  SIGIO is commonly applied to tty's.
The point you made about permission checks is bogus because POSIX won't
let you get SIGIO on anything but your controlling terminal if you
continue with this braindead implementation that calls TIOCSPGRP.

>>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.
>
>Ah.  This, of course, is a property of the shared-ness of descriptors.

Not really.  If sockets can be named in the file system (Unix domain) then
you can get at it by opeing the file (like the printer for instance).

>A dup()ed descriptor (either with the dup() or dup2() system calls,
>or simply shared across fork+exec) has only one underlying object,
>and (for reasons having to do with the basic kernel structure) signals
>have to refer to the underlying object%, hence are shared.
>
>Thus, I think this objection does not apply.  (It *does* apply to tty
>devices.)

This is missing the point completely.  I don't care (and neither do
you) that cooperating processes can hurt each other (a new definition
of cooperating :-)  It's the tty and named socket case that's broken.


Let's take this offline, Chris - I think the horse is dead....
---
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