This change to fs/smb/client/xattr.c is probably safe, and presumably
could be removed in future kernels in a year or two as the updated
cifs-utils which properly checks the error codes is rolled out
broadly.
On Thu, Feb 13, 2025 at 12:42 PM Pali Rohár <pali@xxxxxxxxxx> wrote:
>
> On Wednesday 12 February 2025 19:19:00 Paulo Alcantara wrote:
> > Pali Rohár <pali@xxxxxxxxxx> 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.
>
> Now I quickly prepared a fix, it is straightforward but I have not
> tested it yet. Testing requires non-admin user which does not have
> SeSecurityPrivilege privilege configured. Could you check if it is
> fixing this problem?
--
Thanks,
Steve
