Re: [PATCH net] selinux: fix SCTP client peeloff socket labeling

[Ondrej Mosnacek]

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.