On Fri, Jun 26, 2015 at 1:50 PM, Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
>
> Therefore this changeset marks for backporting the attribute enforcement
> that do not cause regressions in the existing userspace. Implements
> enforcement of nosuid and noexec. Then disables that enforcement of
> nosuid and nosexec and replaces that enforcment with a big fat warning.
> Userspace should be fixed before 4.2 ships so I do not expect these
> warnings to fire.
Eric, that is *not* how this works.
If people have old user-space binaries, we do not require them to be
updated. So it doesn't matter one whit if "Userspace should be fixed
before 4.2 ships", because it is entirely irrelevant if the upstream
project stops doing something, when users want to be able to upgrade
their kernels regardless of whether they've upgraded their system
apps.
I'm going to hold off on pulling this, because I feel you don't
understand the regression rules.
I suggest we instead just always set nosuid and noexec for /proc and
/sys mounts, and make this whole thing a complete non-issue.
Instead of this crazy "let's warn about it and plan on breaking old
existing setups". That's _wrong_. It's so fundamentally wrong that I
will not pull from people who do not understand this.
The reason we have that "no regression" rule is not so that we fix up
bugs. It's because peopel should always feel safe upgrading their
kernel, and basically _know_ that kernel developers consider it
unacceptable to break user space. It should be a warm fuzzy feeling -
the feeling that we try our best, and if we ever fail because we
missed something or really believed that it can't ever matter, we'll
jump on it and we won't be making any excuses for our bugs. Because
breaking user space is a bug.
Kernel developers who don't understand "it is unacceptable to break
user space" shouldn't be kernel developers.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
