On Mon, 2018-04-09 at 01:43 +0800, Xin Long wrote: > On Sun, Apr 8, 2018 at 10:09 PM, Richard Haines > <richard_c_haines@xxxxxxxxxxxxxx> wrote: > > On Sun, 2018-04-08 at 08:50 -0400, Paul Moore wrote: > > > On April 7, 2018 1:03:57 PM Linus Torvalds <torvalds@linux-founda > > > tion > > > .org> wrote: > > > On Sat, Apr 7, 2018 at 9:54 AM, Richard Haines > > > <richard_c_haines@xxxxxxxxxxxxxx> wrote: > > > > > > So please check my resolution, but also somebody should tell me > > > "Linus, you're a cretin, sctp_connect() doesn't want that > > > security_sctp_bind_connect() at all because it was already done > > > by > > > XYZ" > > > > > > sctp_connect() or __sctp_connect() do not need to call > > > security_sctp_bind_connect(). This is because the connect(2) call > > > will > > > handle the checks required via security_socket_connect(): > > > > > > Ok, thanks, that's exactly what I wanted to get. > > > > > > Anyway, somebody should still verify that it all looks good in my > > > tree, but I don't actually expect the merge to have had any > > > issues > > > even if the refactoring made it a bit more complex than most > > > merges > > > are. > > > > > > Thanks for the quick response Richard. > > > > > > Xin Long looked it over and gave it the thumbs up, I'll take a > > > look > > > too, but to be honest I trust his SCTP understanding much more > > > than > > > mine. I also do weekly tests of each rcX release at a minimum so > > > if > > > something odd pops up I'll make sure you get a fix. > > > > > > Thanks again everyone. > > > > I built the kernel this morning and sorry to spoil the party, but > > I've > > run into a problem with lksctp-tools when running the func_tests: > > > > make v6test > > .. > > .. > > ./test_timetolive_v6 > > test_timetolive.c 0 INFO : Creating fillmsg of size 3087 > > test_timetolive.c 1 PASS : Send a message with timeout > > test_timetolive.c 2 PASS : Send a message with no timeout > > test_timetolive.c 3 PASS : Send a fragmented message with timeout > > test_timetolive.c 0 INFO : ** SLEEPING for 3 seconds ** > > test_timetolive.c 4 BROK : Got a datamsg of unexpected length:23, > > expected length:27 > > DUMP_CORE sctputil.c: 247 > > /bin/sh: line 1: 30981 Segmentation fault (core dumped) ./$a > > test_timetolive_v6 fails > > > > make v4 test fails the same way. I'm using lksctp-tools from [1]. I > > have not investigated the cause yet as just found this and thought > > I > > should flag first just in case someone has the answer !!! > > test_timetolive(_v6) works for me, In lksctp-tools/src/func_tests, I > had > another case failed,./test_1_to_1_events, it's caused by: > commit 30f6ebf65bc46161c5aaff1db2e6e7c76aa4a06b > Author: Xin Long <lucien.xin@xxxxxxxxx> > Date: Wed Mar 14 19:05:34 2018 +0800 > > sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT > > It's not kernel's issue, after that commit, ./test_1_to_1_events > should > have been improved. or avoid it by 'sysctl -w net.sctp.auth_enable=1' > > I'm not sure why test_timetolive(_v6) is not working in your env. It appears to depend on the run sequence of the tests. I rebooted the system, ran test_timetolive_v6, it worked okay. Ran "sctp-tests run" on a terminal, then ran test_timetolive_v6 at various intervals on another terminal. Once sctp-tests started the "=== ndatasched ===" sequence, test_timetolive_v6 failed. > > > > > On the bright side, I've run the sctp-tests from [2] with no > > problems > > and also the selinux-testsuite with my SCTP patch from [3] using an > > updated Fedora policy from [4] (with sctp support added), all in > > enforcing mode. > > > > Also the LTP test passed: > > cd /opt/ltp/ > > cat runtest/syscalls |grep connect01>runtest/connect-syscall > > ./runltp -pq -f connect-syscall > > .... > > > > [1] https://github.com/sctp/lksctp-tools > > [2] https://github.com/sctp/sctp-tests > > [3] https://marc.info/?l=selinux&m=152156947715709&w=2 > > [4] https://github.com/fedora-selinux/selinux-policy > > > > > > > > > > -- > > > paul moore > > > www.paul-moore.com > > > > > > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux- > security-module" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
