linux-kernel - Re: RFC: reject unknown open flags

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: <CA+55aFw92r4h4sNW41ifs31ixdZpNmaxY23KthB9R-LXNm7p-w@mail.gmail.com>
Date:   Thu, 30 Mar 2017 10:08:10 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Christoph Hellwig <hch@....de>
Cc:     Alexander Viro <viro@...iv.linux.org.uk>,
        Linux API <linux-api@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        libc-alpha <libc-alpha@...rceware.org>
Subject: Re: RFC: reject unknown open flags

On Thu, Mar 30, 2017 at 9:33 AM, Christoph Hellwig <hch@....de> wrote:
  This really harms
> when adding new flags, because applications can't just probe for the
> flag to actually work.

Side note: this whole argument is also incredibly idiotic from the
very beginning, regardless of the backwards compatibility issue.

But probing for flags is why we *could* add things like O_NOATIME etc
- exactly because it "just worked" with old kernels, and people could
just use the new flags knowing that it was a no-op on old kernels.

The whole concept of "probing for supported features" is very suspect.
It's a bad bad idea. Don't do it.

What kind of new flag did you even have in mind that would have such
broken semantics that it would completely change the other flags?
Becuase now I'm starting to think that the whole series has an even
deeper bug: stupid new features that were badly thought out and not
even described.

             Linus