Re: Change getfacl to print ACL group: (and user:) entries using %u instead of %d?

On Fri, May 22, 2026 at 4:25 AM Peter Eriksson <[email protected]> wrote:
>
> Ran into this the other day (also reported as bug 295444):
>
> # mkdir testdir
>
> # chgrp 3000000005 testdir
>
> # setfacl -x 1 -a 1 group:3000000005:full_set:fd:allow testdir
>
> # getfacl testdir
> # file: testdir
> # owner: root
> # group: 3000000005
>             owner@:rwxpDdaARWcCos:fd-----:allow
>  group:-1294967291:rwxpDdaARWcCos:fd-----:allow
>
>
> Looking at the code in /usr/src/lib/libc/posix1e/acl_to_text_nfs4.c it isn't so surprising:
>
>                 if (grp == NULL)
>                         snprintf(str, size, "group:%d", (unsigned int)*id);
>                 else
>                         snprintf(str, size, "group:%s", grp->gr_name);
>
> (and similar for user:)
>
> uid_t/gid_t are an unsigned 32bit integers on most (all?, at least FreeBSD, Linux, MacOS & Solaris) modern Unix systems, so should be printed using "%u" instead… (In my opinion).
>
>
> The current code makes it difficult to use scripts to extract ACL entries and copy them correctly to new files:
>
> # mkdir newdir
> # getfacl testdir | setfacl -b -n -M - newdir
> setfacl: malformed ACL: unknown user or group name "-1294967291"
> setfacl: -: get_acl_from_file() failed: Invalid argument
>
>
>
> Which is due to it being impossible to set it using the "signed" variant:
>
> # setfacl -x 1 -a 1 group:-1294967291:full_set:fd:allow td
> setfacl: malformed ACL: unknown user or group name "-1294967291"
>
>
> A quick look in the acl_id_to_name.c file used for POSIX ACLs seems to indicate similar %d usage.
>
>
> I think the right way to fix this is to change %d to %u when printing uid_t & gid_t in ACL entries (and since most people are sane enough to not use uid/gid's over 2 billion not many will have noticed this :-).

Sounds reasonable to me. If you put the patch up on reviews.freebsd.org,
I can review it and then commit it (of course, you can select other
reviewers, if you'd like).

rick

>
> - Peter