Re: Regression with getcifsacl(1) in v6.14-rc1

[Paulo Alcantara <pc@manguebit.com>]

Pali Rohár <pali@kernel.org> writes:

> On Wednesday 12 February 2025 17:49:31 Paulo Alcantara wrote:
>> Steve,
>> 
>> The commit 438e2116d7bd ("cifs: Change translation of
>> STATUS_PRIVILEGE_NOT_HELD to -EPERM") regressed getcifsacl(1) because it
>> expects -EIO to be returned from getxattr(2) when the client can't read
>> system.cifs_ntsd_full attribute and then fall back to system.cifs_acl
>> attribute.  Either -EIO or -EPERM is wrong for getxattr(2), but that's a
>> different problem, though.
>> 
>> Reproduced against samba-4.22 server.
>
> That is bad. I can prepare a fix for cifs.ko getxattr syscall to
> translate -EPERM to -EIO. This will ensure that getcifsacl will work as
> before as it would still see -EIO error.

Sounds good.

> But as discussed before, we need to distinguish between
> privilege/permission error and other generic errors (access/io).
> So I think that we need 438e2116d7bd commit.

OK.

> Based on linux-fsdevel discussion it is a good idea to distinguish
> between errors by mapping status codes to appropriate posix errno, and
> then updating linux syscall manpages.

Either way, we shouldn't be leaking -EIO or -EPERM to userland from
getxattr(2).  By looking at the man pages, -ENODATA seems to be the
appropriate error to return instead.