On Tue, 2020-10-20 at 13:55 +0200, Ondrej Mosnacek wrote: > On Fri, Oct 16, 2020 at 3:02 PM Richard Haines > <richard_c_haines@xxxxxxxxxxxxxx> wrote: > > On Thu, 2020-10-15 at 18:04 +0100, Richard Haines wrote: > > > On Thu, 2020-10-15 at 16:12 +0200, Ondrej Mosnacek wrote: > > > > On Thu, Oct 15, 2020 at 3:49 PM Richard Haines > > > > <richard_c_haines@xxxxxxxxxxxxxx> wrote: > > > > > On Thu, 2020-10-15 at 12:28 +0200, Ondrej Mosnacek wrote: > > > > <snip> > > > > > Just a thought - have you tried running the server in one > > > > > terminal > > > > > session and the client in another (I've plugged in your > > > > > Fedora 32 > > > > > addresses): > > > > > > > > > > cd ...tests/sctp > > > > > echo 1 > /proc/sys/net/sctp/addip_enable > > > > > echo 1 > /proc/sys/net/sctp/addip_noauth_enable > > > > > runcon -t sctp_asconf_params_server_t > > > > > ./sctp_asconf_params_server > > > > > 10.0.138.59 10.123.123.123 1035 > > > > > > > > > > cd ...tests/sctp > > > > > runcon -t sctp_asconf_deny_param_add_client_t > > > > > ./sctp_asconf_params_client 10.0.138.59 1035 > > > > > > > > Interesting... I just tried it a couple times and it's not > > > > behaving > > > > consistently - the first time I got "SCTP_PRIMARY_ADDR: > > > > Permission > > > > denied", then 'Dynamic Address Reconfiguration' twice in a row, > > > > then > > > > 7 > > > > times "SCTP_PRIMARY_ADDR: Permission denied", then 'Dynamic > > > > Address > > > > Reconfiguration' 5 times. and then again "SCTP_PRIMARY_ADDR: > > > > Permission denied". > > > > > > > > I tried (manually) different delays between starting the server > > > > and > > > > starting the client, but there didn't seem to be a pattern. > > > > > > > > > > I wonder if this test is flaky. A bit of history: > > > When I first produced the SCTP patches I had different > > > permissions > > > for > > > SCTP_PARAM_SET_PRIMARY, SCTP_PARAM_ADD_IP etc. so that I could > > > detect > > > these denials with allow 'self' rules. However the maintainers > > > wanted > > > to keep things simple with just connect or bind permissions. This > > > made > > > it a bit more difficult to test this case. As it so happened > > > (until > > > now > > > of course), the two LSM calls for SCTP_PARAM_SET_PRIMARY and > > > SCTP_PARAM_ADD_IP in sm_make_chunk.c triggered the following > > > rule: > > > > > > allow sctp_asconf_params_server_t > > > sctp_asconf_deny_param_add_client_t:sctp_socket connect; > > > > > > therefore by not allowing this rule I could detect (using the > > > tshark > > > trace output "Client returns ASCONF_ACK's with 'Request refused - > > > no > > > authorization'") to prove this test case. > > > > > > If this boils down to a timing problem, then the test needs to be > > > removed as I can't test this scenario, because the client needs > > > the > > > connect permission to be able to connect to the server in the > > > first > > > place. > > > > > > > This test does have timimg issues. I put the three asconf tests in > > a > > loop of 200 iterations. Sometimes all would pass, but other times > > the > > third test would fail with the error. > > > > I guess there are two options: Revert the patch, or remove the > > offending test. Any views !!! > > And do you think that the timing issue can be fixed by better > synchronizing the client and server programs or is it inherently > unavoidable? If you think it could be fixed in some way (even if > non-trivial), then I'd prefer to just comment out the test with a > note > to revisit it in the future (leaving the code in place for now). I'll > try to look into it at some point, unless you're faster than me :) I do have a possible new test for the 3rd asconf test that I've run through 5000 interations without error, whereas the current one would fail between 100 to 500 interations (I changed the 'tm.tv_sec = 3;' client timer to 'tm.tv_usec = 50000;' so it ran faster). I hope to send updates late next week. Note that I've had no problems running the 1st and 2nd asconf tests in these loops. >
