From: "Darrick J. Wong" <djwong@kernel.org>
To: Theodore Tso <tytso@mit.edu>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 0/7] fix up issues from djwong/fuse4fs-fork
Date: Tue, 5 May 2026 08:58:21 -0700 [thread overview]
Message-ID: <20260505155821.GI1101423@frogsfrogsfrogs> (raw)
In-Reply-To: <20260505072144.GC16497@macsyma-wired.lan>
On Tue, May 05, 2026 at 09:21:44AM +0200, Theodore Tso wrote:
> On Mon, May 04, 2026 at 05:08:31PM -0700, Darrick J. Wong wrote:
> > Hm, curious. It's regrettable that I no longer have a Mac, and
> > therefore can't really do much investigating. If you give
> > -o default_permissions,allow_other , does that fix the problem?
> > If that fixes it, then fuse2fs has a bug somewhere in its own
> > permissions checking.
>
> Nice catch! Yes, using default_permissions does fix things. So now I
> need to figure out what changed between v1.47.4 and next, and what
> default_permissions does. I notice that in kernel mode we enable
> default_permissions?
Yes. Though the addition of allow_other and default_permissions was
exactly the same in 1.47.4.
> Can you give me a suggestion at what I might try to look at next?
Hrm. A bisect would be the best (but least conference-friendly) option
to narrow things down.
On Linux, adding "default_permissions" means that the kernel uses the
same permission checking code that it uses for in-kernel filesystems.
Without it, the fuse server is responsible for doing all permission
checking.
And now that I've tried it, there are bugs in fuse2fs' permission
checking (aka !default_permissions):
# fuse2fs /dev/sda /mnt -d -f -o iomap=0,allow_other
# mkdir /mnt/lost+found/frogs
# su - djwong
$ ls -d /mnt/ /mnt/lost+found/ /mnt/lost+found/frogs/
drwxr-xr-x 3 root root 4096 May 5 08:32 /mnt//
drwx------ 3 root root 16384 May 5 08:49 /mnt/lost+found//
drwxr-xr-x 2 root root 4096 May 5 08:49 /mnt/lost+found/frogs//
So I guess I'm still confused. I've wondered if fuse2fs should always
inject default_permissions?
--D
next prev parent reply other threads:[~2026-05-05 15:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 23:32 [PATCH 0/7] fix up issues from djwong/fuse4fs-fork Theodore Ts'o
2026-05-04 23:32 ` [PATCH 1/7] libsupport: drop xbitops.h and define fls() if necessary Theodore Ts'o
2026-05-05 0:11 ` Darrick J. Wong
2026-05-04 23:32 ` [PATCH 2/7] configure.ac: fix disable fuse2fs/fuse4fs by default path Theodore Ts'o
2026-05-05 0:13 ` Darrick J. Wong
2026-05-04 23:32 ` [PATCH 3/7] libsupport: don't use bzero in cache.c Theodore Ts'o
2026-05-05 0:15 ` Darrick J. Wong
2026-05-04 23:32 ` [PATCH 4/7] fuse[24]fs: suppress clang warnings which were breaking the github CI Theodore Ts'o
2026-05-05 0:20 ` Darrick J. Wong
2026-05-04 23:32 ` [PATCH 5/7] libsupport: remove the LIST_HEAD macro from list.h Theodore Ts'o
2026-05-05 0:20 ` Darrick J. Wong
2026-05-04 23:33 ` [PATCH 6/7] libsupport: fix gcc -Wall warnings Theodore Ts'o
2026-05-05 0:20 ` Darrick J. Wong
2026-05-04 23:33 ` [PATCH 7/7] fuse2fs: fix uninitialized variable warnings Theodore Ts'o
2026-05-05 0:26 ` Darrick J. Wong
2026-05-05 0:08 ` [PATCH 0/7] fix up issues from djwong/fuse4fs-fork Darrick J. Wong
2026-05-05 7:21 ` Theodore Tso
2026-05-05 15:58 ` Darrick J. Wong [this message]
2026-05-05 22:04 ` Theodore Tso
2026-05-05 22:56 ` Darrick J. Wong
2026-05-06 9:28 ` Theodore Tso
2026-05-06 14:34 ` Darrick J. Wong
2026-05-06 15:08 ` Theodore Tso
2026-05-06 16:39 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260505155821.GI1101423@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.