Non-trivial ACLs only?

[Edward Tomasz Napierała]

On 0713T2202, Dr. Rolf Jansen wrote:
> Am 13.07.2014 um 15:55 schrieb Edward Tomasz Napierała <trasz at FreeBSD.org>:
> 
> > On 0713T1215, Dr. Rolf Jansen wrote:
> >> 
> >> ...
> >> On Mac OS X, acl_get_link_np() returns real ACLs only, can I have this somehow for FreeBSD too?
> > 
> > No, because it's a bug. Unfortunately I don't expect Apple to fix their implementation.
> 
> If it's a bug, then for my purpose it's a very welcome one, because it keeps things easy on Mac OS X. So, I hope Apple keeps it as it is. 

Heh, yeah, well.  It's a matter of personal preference, I guess :-)

> > This one is wrong.  There is no such thing as trivial default
> > ACL.  If you can actually retrieve ACL_TYPE_DEFAULT ACL and
> > there are any entries in it, it's non-trivial.
> > 
> > ...
> > 
> >> This doesn't seem to work properly for directories, any ideas why?
> > 
> > I think it's the problem above.
> 
> OK, how then can I find out if there are ACLs set on directories or not. Please consider the following code snippet:

Two of the three cases in your mail were correct.  It's just
that the one for ACL_TYPE_DEFAULT was wrong.

> #include <stdio.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <sys/acl.h>
> 
> int main(int argc, char *const argv[])
> {
>    mkdir("test_acl_dir", 0755);
> 
>    if (acl_get_link_np("test_acl_dir", ACL_TYPE_DEFAULT))
>       printf("ACL found.\n");
>    else
>       printf("ACL not found.\n");
> 
>    return 0;
> }
> 
> clang acltest.c -o acltest
> rm -rf test_acl_dir && ./acltest
> 
> On FreeBSD 9.2, the above command sequence results in "ACL found." Actually no ACL has been set, and I would have expected, that any acl_get_*() function would have returned NULL. So, why does it return a result which is so completely non-sense for the copy purpose?

Because NULL return means error, and in this case there is no
error - it's just that there is no default ACL set.  In FreeBSD,
this is expressed by empty (zero entries) ACL.

> The same on Mac OS X 10.9.4 (type argument changed to ACL_TYPE_EXTENDED) gives: "ACL not found." So even if it's a bug, it's at least a bug that makes sense very much.
> 
> >> Isn't there a better way?
> > 
> > Actually, there is.  You try to obtain both POSIX and NFSv4
> > ACLs for every file, even though the filesystem can always
> > support either one, or the other.
> > 
> > Take a look how eg. the cp(1) utility does it.  The source
> > code is here:
> > 
> > http://svnweb.freebsd.org/base/head/bin/cp/utils.c?revision=245960&view=markup
> > 
> > Look for preserve_fd_acls() function.
> 
> OK, I got this one.
> 
> Anyway, I have two doubts left:
> 1. Is it correct that ACL_TYPE_DEFAULT is applicable for directories only, or do regular files may have DEFAULT ACLs beside ACCESS or NFSv4?

The default ACL may only be set on directories.  It may never be used
with NFSv4 ACLs, ie. can only be used with POSIX (ACL_TYPE_ACCESS) ACLs.

> 2. What about hard links? Do all hard links of one inode share the same ACL, or may each hard link have a different one?

Yes, all hard links share the same ACL.

> >> Is it really necessary to assemble the standard access rights into an ACL, I did not expect this, Mac OS X doesn't do this, and in the present situation it spoils up everything.
> > 
> > Well, yes, because the standard UNIX permissions are a part of ACL by definition.
> 
> OK, however, the extra assembly could easily be done in user space, and also http://svnweb.freebsd.org/base/head/bin/cp/utils.c would benefit from acl_*_np() functions that return only something if it is different from the standard UNIX permissions, because any copy utility needs to deal with the latter in any case. In the present situation we need to deal with the standard UNIX perms more than twice.
> 
> >> Anyway, for the present purpose it would be great to have at least a function which simply informs whether a file system item got a non-trivial ACL or not, without actually needing to load that ACL into memory.
> > 
> > I don't think there would be any measurable speedup.  You still
> > need to use a syscall to do this, and the syscall would need to
> > access ACL metadata.  The only difference from what you're doing
> > right now is calling acl_is_trivial_np() and perhaps acl_free(),
> > which are both just a library functions, and thus cheap.
> 
> I still think a simple ACL introspection syscall -- one which returns status codes only, and not the whole lot -- would be very useful.

Still, it would be only marginally faster (if at all) than a routine
that retrieves the ACL and then check whether it's trivial.