Re: [PATCH v5 0/4] Introduce security_create_user_ns()

[Paul Moore]

On Wed, Aug 17, 2022 at 11:08 AM Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
> > I just merged this into the lsm/next tree, thanks for seeing this
> > through Frederick, and thank you to everyone who took the time to
> > review the patches and add their tags.
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git next
>
> Paul, Frederick
>
> I repeat my NACK, in part because I am being ignored and in part
> because the hook does not make technical sense.
>
> Linus I want you to know that this has been put in the lsm tree against
> my explicit and clear objections.

Eric, we are disagreeing with you, not ignoring you; that's an
important distinction.  This is the fifth iteration of the patchset,
or the sixth (?) if you could Frederick's earlier attempts using the
credential hooks, and with each revision multiple people have tried to
work with you to find a mutually agreeable solution to the use cases
presented by Frederick and others.  In the end of the v4 discussion it
was my opinion that you kept moving the goalposts in an effort to
prevent any additional hooks/controls/etc. to the user namespace code
which is why I made the decision to merge the code into the lsm/next
branch against your wishes.  Multiple people have come out in support
of this functionality, and you remain the only one opposed to the
change; normally a maintainer's objection would be enough to block the
change, but it is my opinion that Eric is acting in bad faith.

At the end of the v4 patchset I suggested merging this into lsm/next
so it could get a full -rc cycle in linux-next, assuming no issues
were uncovered during testing I was planning to send it to Linus
during the next merge window with commentary on the contentiousness of
the patchset, including Eric's NACK.  I'm personally very disappointed
that it has come to this, but I'm at a loss of how to work with you
(Eric) to find a solution; this is the only path forward that I can
see at this point.  Others have expressed their agreement with this
approach, both on-list and privately.

If anyone other than Eric or myself has a different view of the
situation, *please* add your comments now.  I believe I've done a fair
job of summarizing things, but everyone has a bias and I'm definitely
no exception.

Finally, I'm going to refrain from rehashing the same arguments over
again in this revision of the patchset, instead I'll just provide
links to the previous drafts in case anyone wants to spend an hour or
two:

Revision v1
https://lore.kernel.org/linux-security-module/20220621233939.993579-1-fred@xxxxxxxxxxxxxx/

Revision v2
https://lore.kernel.org/linux-security-module/20220707223228.1940249-1-fred@xxxxxxxxxxxxxx/

Revision v3
https://lore.kernel.org/linux-security-module/20220721172808.585539-1-fred@xxxxxxxxxxxxxx/

Revision v4
https://lore.kernel.org/linux-security-module/20220801180146.1157914-1-fred@xxxxxxxxxxxxxx/

--
paul-moore.com