On 06/23/2015 01:12 PM, Paul Moore wrote: > On Tue, Jun 23, 2015 at 8:47 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: >> On 06/22/2015 05:56 PM, Paul Moore wrote: >>> On Mon, Jun 22, 2015 at 4:40 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: >>>> There was a bug in the unix and inet socket tests: >>>> the server program would exit as soon as it finished >>>> responding to the legitimate client, so the unauthorized >>>> client tests were "succeeding" due to the server socket >>>> not even existing rather than a permission denial. Fix >>>> the server to stay around until it is explicitly killed by >>>> the test scripts. This fix then revealed a problem with the >>>> last inet_socket test: although the permission denial correctly >>>> prevents the server from receiving the datagram message, the >>>> client gets no notification of this failure and hangs on its >>>> subsequent attempt to read a reply from the server. Remove >>>> that last test until we come up with a suitable way of testing. >>> >>> How about a AF_UNIX side channel to communicate success/failure >>> between the client and server? >> >> I could be wrong, but I don't believe that a peer recv denial is visible >> to either side in the datagram (UDP) case. Server application just >> won't receive anything, and client won't get any notification of error >> on the write, so there is no way for the server to even know that it >> didn't get anything in order to tell the server of the failure. Only >> fix I can see would be to have the client poll with some kind of >> timeout, and assume that a failure to reply within a certain window >> indicates failure to receive, but that's obviously not 100%. > > My thinking was that the client/server could communicate over the side > channel that they are/trying to talk with the other end. Like > polling, it isn't perfect, but assuming a reasonable system it should > okay to assume failure after a few seconds. > > If I recall correctly, we do something similar in the CC tests for networking. I don't suppose those tests are open source and available somewhere? _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
