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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
