Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux

[Andreas Grünbacher]

Am Mo., 7. Nov. 2022 um 13:45 Uhr schrieb Ondrej Valousek
<ondrej.valousek.xm@renesas.com>:
> Hi Andreas,
> Can you please clarify this?

Gnulib commit da6ebc941 ("acl: On Linux, check for acls without
libacl") switched from acl_extended_file to getxattr to avoid a
runtime dependency on libacl. I think that was mainly a benefit during
bootstrapping and in degraded environments. It's been a while, though.

> Note I have also submitted a possible patch to the libacl, in case we do not 
> want to put this functionality to gnulib.

libacl only knows about POSIX ACLs, and that's on purpose to some
degree. The other kinds of ACLs work quite differently, such that the
POSIX ACL API doesn't match those kinds of ACLs very well. (For
example, the order of entries in POSIX ACLs doesn't matter / is
predefined, while different orders can lead to different results in
the NFSv4 ACL world.) It wouldn't make any sense to support NFSv4 ACLs
in acl_extended_file() only.

As far as support for Linux's client-side view of NFSv4 ACLs in
gnulib's file_has_acl() function goes, there is precedent for that for
other systems and kinds of ACLs, so I don't see why it shouldn't be
added there. It's a hopeless and unfixable mess already, and that
particular quirk won't change a thing.

The implementation should be changed to at least use a static buffer
on the stack that's just big enough for trivial NFSv4 ACLs. Instead of
probing the size and then reading the ACL, read the ACL right away. If
there is no ACL or if the ACL is trivial, we'll know right away. If
the ACL is too big, it must be non-trivial.

> Afaik you are also maintainer of libacl... right?
> Thanks
> Ondrej

Thanks,
Andreas