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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 15 Nov 2016 07:53:06 -0800
From:   Nikolaus Rath <Nikolaus@...h.org>
To:     Miklos Szeredi <mszeredi@...hat.com>
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 Nov 15 2016, Miklos Szeredi <mszeredi@...hat.com> wrote:
> 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.

Alright, thanks.

ENOSYS is actually treated specially for several handlers. Sometimes it
means "don't call this handler again and always fail" (getxattr et al),
sometimes it means "don't call this handler again and always succeed"
(flush, fsyncdir), and sometimes the behavior depends on the kernel
version (open).

I think I will add explicit descriptions how ENOSYS is treated to each
affected handler, and otherwise recommend to "use error codes from the
syscall manpages where possible".


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«