On Thu, Nov 11, 2021 at 4:44 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > On Thu, Nov 11, 2021 at 7:59 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > 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... > > DaveM is stubbornly rejecting the revert requests so for now I would > continue to base any patches on top of the netdev tree. If that > changes we can reconcile any changes as necessary, that should not be > a major issue. > > As far as what I would like to see from the patches, ignoring the > commit description vs cover letter discussion, I would like to see > patches that fix all of the known LSM/SELinux/SCTP problems as have > been discussed over the past couple of weeks. Even beyond this > particular issue I generally disapprove of partial fixes to known > problems; I would rather see us sort out all of the issues in a single > patchset so that we can review everything in a sane manner. In this > particular case things are a bit more complicated because of the > current state of the patches in the netdev tree, but as mentioned > above just treat the netdev tree as broken and base your patches on > that with all of the necessary "Fixes:" metadata and the like. Hm, okay, that isn't what I was branch-predicting from your other responses, but works for me. > > 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... > > It's not clear to me from your comments above if this is something you > are currently working on, planning to work on soon, or giving up on in > the near term. Are we able to rely on you for a patchset to fix this > or are you unable to see this through at this time? I'm still working on it, but I'll need to juggle it with other things now and I might need to defer it completely at some point. I don't think I'll have all the patches ready sooner than two weeks from now. My point was to explain that I'm unable to provide a proper fix in the short term and don't want to block the netdev maintainers in case they were waiting for this to get resolved before e.g. sending a PR to Linus. -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
