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.
