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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 11 Nov 2016 00:12:20 +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@...nel.org
Subject: Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT
 flag to INIT

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.

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.

Thanks,
Miklos