bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC acl port to FreeBSD (and maybe solaris)


From: Andreas Grünbacher
Subject: Re: RFC acl port to FreeBSD (and maybe solaris)
Date: Tue, 30 Jun 2015 21:00:27 +0200

Pádraig,

thanks for looking into this.

2015-06-30 14:32 GMT+02:00 Pádraig Brady <address@hidden>:
> The crux of the patch is to set the acl_no_supported flag
> when getting permissions and get such an errno.

That's not how this should work; the flag is there for set_permissions
internal use. The source and target file may have different kinds of
acl support. In get_permissions, when acls are not supported, only
ctx->mode should be set. In set_permissions, we try to set_acls the
first time. If that fails, set_acls sets the acls_not_supported flag.
It is then retried and the flag tells it to try setting the acls based
on ctx->mode. This is needed on systems which support different kinds
of acls on different file systems.

Whether failing to set an acl is an error or not depends on the acl:
if the acl is equivalent to the file mode, we can just do a chmod
instead; otherwise, we are losing information, and we need to tell the
user. See the "nontrivial" functions in the code.

I've tried to get a recent version of Solaris running inside qemu/kvm
so I can debug  these problems myself, unfortunately with no luck. I
haven't had time to try FreeBSD yet.

> Also I've reinstated the acl_from_mode() replacement
> in set-permissions.c which was ignored due to defines in acl-internal.h

Hmm, what's using that? It can't be set_permissions: that still errors
out when HAVE_ACL_FROM_TEXT isn't defined, which is when
rpl_acl_from_mode is defined.

acl_from_mode() cannot fail because of lack of acl support on a file
system, it doesn't access the file system. It shouldn't affect the
acls_not_supported flag.

Thanks,
Andreas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]