Well, I sort of understand your concern.
The "problem" here is:
1. You are doing a similar stuff already - check the code for Solaris for
example.
2. I am happy to try to push this code into the libacl (where it would
naturally should be probably), but then we need to get rid of the (fairly
recently added) code:
# if GETXATTR_WITH_POSIX_ACLS
ssize_t ret;
ret = getxattr (name, XATTR_NAME_POSIX_ACL_ACCESS, NULL, 0);
...
#elsif HAVE_ACL_GET_FILE
.. and call acl_extended_file() function from libacl. I then move my code into
this function.
So in nutshell I do not quite understand why we are not calling
acl_extended_file() any more on Linux. Maybe to simplify code & one less
dependency?
Any suggestions here?
-----Original Message-----
From: Paul Eggert <egg...@cs.ucla.edu>
Sent: neděle 30. října 2022 19:37
To: Ondrej Valousek <ondrej.valousek...@renesas.com>; Bruno Haible
<br...@clisp.org>; bug-gnulib@gnu.org
Subject: Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux
On 2022-10-28 07:33, Ondrej Valousek wrote:
> 2. The 'acl' package (as of today) only supports Posix ACLs and not the NFSv4
> style. And besides, we do not use it anyway on modern Linux distros - see the
> code, instead of calling acl library, we just call getxattr() function
> directly.
Is that the best we can do? Surely we shouldn't expect user code to contain
gems like this:
u_int32_t num_aces = (u_int32_t)ntohl(*((u_int32_t*)(xattr))); /* Grab the
number of aces in the acl
Wouldn't it be better to put this sort of thing into a library with a
well-defined API (you can call it "nfsacl" if you like) and have Gnulib use
that library? Gnulib is supposed to be a portability library, not a packet
sniffer.
