Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #1251698

Bug#1108534: e2fsprogs: getfattr returns different values for posix acls when using fuse2fs

From Tim Woodall <tim@woodall.me.uk>
Newsgroups linux.debian.bugs.dist
Subject Bug#1108534: e2fsprogs: getfattr returns different values for posix acls when using fuse2fs
Date 2025-07-03 00:40 +0200
Message-ID <L4ehr-eOnH-17@gated-at.bofh.it> (permalink)
References (1 earlier) <L3WNz-eCIM-1@gated-at.bofh.it> <L4aQx-eM4i-1@gated-at.bofh.it> <L4d21-eNCE-3@gated-at.bofh.it> <L3rqp-eigc-1@gated-at.bofh.it> <L4d21-eNCE-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, 2 Jul 2025, Theodore Ts'o wrote:

> On Wed, Jul 02, 2025 at 07:44:24PM +0100, Tim Woodall wrote:
>>
>> So it seems that my change is only needed on older kernels.
>>
>
> OK, thanks for the hint.  Using the same fuse2fs binary (built in a
> bookworm-amd64 chroot), I can replicate what you're seeing on 6.1.142:
>

> The thing is, for the ACL types in question, the kernel shouldn't even
> be looking at e_id; that field is undefined for ACL_USER_OBJ,
> ACL_GROUP_OBJ, et.al, since the kernel would be using the inode's user
> and group ownership, and for ACL_MASK and ACL_OTHER there is no id
> number to be used.  So the kernel shouldn't even be *looking* at that
> field.  So whether the value is 0 or -1 shouldn't make a difference.
> And change that I don't understand always give me pause....
>
I agree. I tried digging through the kernel code but I couldn't work out 
where the -1 wad coming from when not using fuse. I thought zero seemed 
more likely! If I followed the right bits there's a kvzmalloc where it 
goes to userspace.  I gave up at this point, I don't know kernel 
programming and I was probably wasting my time.

> BTW, what caused you to think that -1 might fix things on a Bookworm
> 6.1 kernel?
>

Here is near identical code:

https://sourceforge.net/p/dump/code/ci/main/tree/restore/xattr.c#l284

and this is how I found it (by luck) when an EA failed to verify.

I patched this code (to match libext2fs) and then recently discovered 
that it wad now failing when not testing on fuse.

I don't think this 0/-1 value is used, it's just exposed via the 
getfattr interface to this EA.

Tim.

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Bug#1108534: e2fsprogs: getfattr returns different values for posix acls when using fuse2fs Tim Woodall <debianbugs@woodall.me.uk> - 2025-06-30 20:30 +0200
  Bug#1108534: e2fsprogs: getfattr returns different values for posix acls when using fuse2fs "Theodore Ts'o" <tytso@mit.edu> - 2025-07-02 06:00 +0200
    Bug#1108534: e2fsprogs: getfattr returns different values for posix acls when using fuse2fs Tim Woodall <debianbugs@woodall.me.uk> - 2025-07-02 21:00 +0200
      Bug#1108534: e2fsprogs: getfattr returns different values for posix acls when using fuse2fs "Theodore Ts'o" <tytso@mit.edu> - 2025-07-02 23:20 +0200
        Bug#1108534: e2fsprogs: getfattr returns different values for posix acls when using fuse2fs Tim Woodall <tim@woodall.me.uk> - 2025-07-03 00:40 +0200

csiph-web