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:   Fri, 11 Nov 2016 09:43:12 +0100
From:   Miklos Szeredi <mszeredi@...hat.com>
To:     Nikolaus Rath <Nikolaus@...h.org>
Cc:     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 5:57 AM, Nikolaus Rath <Nikolaus@...h.org> wrote:
> 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.

ENOSYS is not a valid return value for any existing syscall.  Fuse
uses that fact to attach this special meaning to ENOSYS.  So
compatibility is not an issue here, old filesystems should never
return ENOSYS from open.

Thanks,
Miklos