On Tue, Nov 9, 2021 at 4:00 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > On Tue, Nov 9, 2021 at 9:21 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Thu, 4 Nov 2021 20:59:49 +0100 Ondrej Mosnacek wrote: > > > As agreed with Xin Long, I'm posting this fix up instead of him. I am > > > now fairly convinced that this is the right way to deal with the > > > immediate problem of client peeloff socket labeling. I'll work on > > > addressing the side problem regarding selinux_socket_post_create() > > > being called on the peeloff sockets separately. > > > > IIUC Paul would like to see this part to come up in the same series. > > Just to reaffirm the IIUC part - yes, your understanding is correct. The more I'm reading these threads, the more I'm getting confused... Do you insist on resending the whole original series with modifications? Or actual revert patches + the new patches? Or is it enough to revert/resend only the patches that need changes? Do you also insist on the selinux_socket_post_create() thing to be fixed in the same series? Note that the original patches are still in the net.git tree and it doesn't seem like Dave will want to rebase them away, so it seems explicit reverting is the only way to "respin" the series... Regardless of the answers, this thing has rabbithole'd too much and I'm already past my free cycles to dedicate to this, so I think it will take me (and Xin) some time to prepare the corrected and re-documented patches. Moreover, I think I realized how to to deal with the peer_secid-vs.-multiple-assocs-on-one-socket problem that Xin mentions in patch 4/4, fixing which can't really be split out into a separate patch and will need some test coverage, so I don't think I can rush this up at this point... In the short term, I'd suggest either reverting patches 3/4 and 4/4 (which are the only ones that would need re-doing; the first two are good changes on their own) or leaving everything as is (it's not functionally worse than what we had before...) and waiting for the proper fixes. -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
