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]

Date:   Thu, 10 Nov 2016 20:57:30 -0800
From:   Nikolaus Rath <Nikolaus@...h.org>
To:     Miklos Szeredi <mszeredi@...hat.com>
Cc:     Andrew Gallagher <andrewjcg@...com>,
        lkml <linux-kernel@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org
Subject: Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 11 2016, Miklos Szeredi <mszeredi@...hat.com> wrote:
> On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath <Nikolaus@...h.org> wrote:
>> Hi Andrew,
>>
>> In commit d7afaec0b564f0609e116f5 you added a new FUSE_NO_OPEN_SUPPORT
>> flag. But as far as I can tell, the flag is simply accepted without
>> having any effect (including in libfuse).
>>
>> I tried to find related later commits, but did not find anything either.
>>
>> Am I missing something?
>
> Hmm, if fuse fs detects this flag, then it can return ENOSYS from open
> resulting in this and subsequent opens succeeding without further
> calls to userspace.    If fuse fs doesn't detect this flag, it should
> not return -ENOSYS, as that will result in the open failing, it should
> instead implement a no-op open method.

That doesn't sound like a good approach to me. That way, the file system
has to *know* that this flag has been introduced in order to behave
correctly, i.e. filesystems that predate the introduction of the flag
will suddenly behave differently.

I think the correct behavior would be to for the kernel to check if
userspace passed the flag, and treat ENOSYS specially if and only if the
flag was passed.

> Could handle this in libfuse and that would make things easier for
> filesystem implementors that would want to use this feature.  But I
> guess its use is relatively rare and so it doesn't really matter.

I agree, but it would be nice to get this sorted out properly
nevertheless. If nothing else, it will make the behavior easier to
explain.

Would you accept a patch that makes treatment of ENOSYS conditional on
userspace passing the flag (as outlined above)?


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.«