On Tue, Sep 12, 2000 at 02:45:48AM +0200, jury gerold wrote:
> Andi Kleen wrote:
> >
> > On Tue, Sep 12, 2000 at 02:20:02AM +0200, jury gerold wrote:
> > > I ran into a problem with 2.2.x kernels, posix signals and sockets.
> > >
> > > I have a program that creates a serversocket, puts it into listen state,
> > > attaches the socket to a realtime signal and simply waits for the signal.
> > >
> > > When i create a connection (telnet a.b.c.d port) the signal is delivered depending
> > > on the user that does the telnet.
> > > If root creates the socket, then only root or another machine is able to trigger the signal
> > > by connecting to the socket.
> > > Normal users are only able to create a SIGIO signal when connecting.
> >
> > That's very unlikely. TCP does not propagate gid/uid information over sockets,
> > not even over localhost.
> > There was probably some other factor during your tests. When you overflow
> > the rt signal queue then the kernel will fall back to sending SIGIO. In
> > this case you have to collect outstanding events using poll.
> >
> > -Andi
> > -
>
> Thats right. A connection from a different machine always triggers the realtime signal.
> On the same machine however, it depends on the user that does the connect and on the
> user that creates the listening socket.
I doubt it.
>
> While you mention it : Somewhere in net/socket.c there is a connection between SIGIO and SO_NOSPACE.
The sending socket has no ties at all to the receiving socket other than
that they speak TCP/IP with each other. The receiver socket socket simply does
not know the uid, so it cannot change behaviour based on it.
The "connection" to SO_NOSPACE is easy to explain, see the table of I/O events
in socket(7). It is the POLLOUT event.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:16 EST