linux-kernel - Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on userns mounts, breaking systemd-nspawn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPP7u0Vo6gB86S-hZcOW9Rmki8oKHd=Lyx3x-N9gjPC4JP_YxQ@mail.gmail.com>
Date:   Sat, 22 Dec 2018 23:48:54 +0100
From:   Christian Brauner <christian.brauner@...onical.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     nix.or.die@...il.com, "Eric W. Biederman" <ebiederm@...ssion.com>,
        ellierevves@...il.com,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Seth Forshee <seth.forshee@...onical.com>
Subject: Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on
 userns mounts, breaking systemd-nspawn

On Sat, Dec 22, 2018 at 11:20 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Eric, this is entirely unacceptable.

i would like to point out that I send a revert for this in *July*
before any kernel with this change
was released for the exact same reason. But I was ignored and no one
came to argumentative aid:
- https://lists.linuxfoundation.org/pipermail/containers/2018-July/039182.html
- https://lists.linuxfoundation.org/pipermail/containers/2018-July/039183.html

To be fair, no one apart from me was pointing out that it actually
breaks people including systemd folks
even though I was bringing it up with them. I even tried to fix all of
userspace after this got NACKED
( https://github.com/systemd/systemd/pull/9483 ).

Christian

>
> On Sat, Dec 22, 2018 at 12:58 PM Gabriel C <nix.or.die@...il.com> wrote:
> >
> > Added some people to CC that might want to see this..
>
> Thanks.
>
> > > Here's an email that was sent to lkml about the subject:
> > >
> > > https://lkml.org/lkml/2018/7/5/742
> > >
> > > I link also this, quoting the last of it:
> > >
> > > https://lkml.org/lkml/2018/7/5/701
> > >
> > > It has never been the case that mknod on a device node will guarantee
> > > that you even can open the device node.  The applications that regress
> > > are broken.  It doesn't mean we shouldn't be bug compatible, but we darn
> > > well should document very clearly the bugs we are being bug compatible with.
>
> Yeah, this is complete garbage.
>
> We have very clear rules in the kernel: if some change breaks existing
> setups, it is ABSOLUTELY NEVER the application that is broken.
>
> It is the kernel.
>
> There is absolutely zero gray areas here. Eric, your behavior is
> entirely out of line, and now we apparently have a regression that
> goes back to June that I was not told about because of your incorrect
> stance.
>
> Eric, I want to make this 1000% clear: there are no user space bugs.
> If it used to work, then user space was clearly doing the right thing.
> The fact that you tried to several times claim it was buggy user space
> is a serious breach of trust. You KNOW this is the case.
>
> Seriously. There are no excuses.
>
> That commit is now reverted in my tree, and furthermore I will not
> take any pull requests from you until you have made it clear that you
> comprehend this very fundamental issue.
>
> Why did it take so long for this issue to be elevated to me?
>
>                    Linus