Non-trivial ACLs only?

[Dr. Rolf Jansen]

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. 

> 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:

#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?

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?
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?

>> 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.

Best regards

Rolf