linux-kernel - Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN

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: <CAOssrKcOe_Mbb4hLJ8CW0s5+8qRhMdy4AtsWuUzLAJ9qDEBxYw@mail.gmail.com>
Date:   Tue, 15 Nov 2016 14:33:22 +0100
From:   Miklos Szeredi <mszeredi@...hat.com>
To:     Nikolaus Rath <Nikolaus@...h.org>
Cc:     Mike Marshall <hubcap@...ibond.com>,
        Andrew Gallagher <andrewjcg@...com>,
        lkml <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT
 flag to INIT

On Fri, Nov 11, 2016 at 6:27 PM, Nikolaus Rath <Nikolaus@...h.org> wrote:

> Yeah, I'd expect most people to do that. But FUSE file systems are often
> a little more exotic and produce error conditions that don't match well
> with any of the codes documented in the manpages. If there is no good
> fit, I'd expect that most people would (as I have done so far) simply
> pick something more appropriate from errno(3). If some of these codes
> are forbidden (or only a subset allowed) I'd really like to document
> this. It's not reasonable to expect every libfuse user to start browsing
> the Linux VFS code to determine if they can use a particular error code.

The library and the kernel checks for -1000 < error <= 0.  There are
no other checks done by fuse.  However returning ENOSYS for open is
simply wrong, it's definitely not something a sane filesystem would
ever do.

Thanks,
Miklos