lkml.org 
[lkml]   [2022]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v5 0/4] Introduce security_create_user_ns()
    On Wed, Aug 17, 2022 at 11:08 AM Eric W. Biederman
    <ebiederm@xmission.com> 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@cloudflare.com/

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

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

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

    --
    paul-moore.com

    \
     
     \ /
      Last update: 2022-08-17 18:03    [W:2.145 / U:0.188 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site