Re: cp giving "Operation not applicable" on newer solaris

[Andreas Grünbacher]

2016-11-26 23:00 GMT+01:00 Pádraig Brady <address@hidden>:
> Testing on "SunOS 5.10 Generic_150400-17 sun4v sparc" on tmpfs,
> all tests pass except for `cp -a` returning an error copying ACLs.
> The diagnostic is for ENOSYS, and glancing at the gnulib code
> suggests it should fall back to chmod on ENOSYS, rather than failing...
>
> `mkdir x && truss cp -a x y` gives:
>
> acl("x", ACE_GETACLCNT, 0, 0x00000000)          = 3
> acl("x", ACE_GETACL, 3, 0x00040050)             = 3
> acl("x", GETACLCNT, 0, 0x00000000)              = 4
> acl("x", GETACL, 4, 0x00040080)                 = 4
> acl("y", SETACL, 4, 0x00040080)                 Err#89 ENOSYS
> acl("y", ACE_SETACL, 3, 0x00040050)             Err#89 ENOSYS
> acl("y", ACE_GETACL, 333, 0xFFBFE148)           = 3
> acl("y", ACE_SETACL, 6, 0xFFBFE100)             Err#89 ENOSYS
>
>
> Digging a little for the ACL entry causing the fallback to chmod
> to not suffice, shows that it's the NEW_ACE_DELETE_CHILD bit
> that's causing the issue. The following tentative patch
> avoids checking that bit, and thus the diagnostic and EXIT_FAILURE:
>
> diff --git a/lib/acl-internal.c b/lib/acl-internal.c
> index 4de60c3..e56d28f 100644
> --- a/lib/acl-internal.c
> +++ b/lib/acl-internal.c
> @@ -252,7 +252,8 @@ acl_ace_nontrivial (int count, ace_t *entries)
>        access_masks[1] &= ~(NEW_ACE_WRITE_NAMED_ATTRS
>                             | NEW_ACE_WRITE_ATTRIBUTES
>                             | NEW_ACE_WRITE_ACL
> -                           | NEW_ACE_WRITE_OWNER);
> +                           | NEW_ACE_WRITE_OWNER
> +                           | NEW_ACE_DELETE_CHILD);
>        if ((NEW_ACE_READ_NAMED_ATTRS
>             | NEW_ACE_READ_ATTRIBUTES
>             | NEW_ACE_READ_ACL

The NEW_ACE_DELETE_CHILD permission has no meaning for
non-directories. In a mode-equivalent ACL of a directory, ACEs should
either have both NEW_ACE_WRITE_DATA and NEW_ACE_DELETE_CHILD set, or
neither of the two.

The permission isn't owner specific, so the above change looks incomplete.

> So we can we read this bit but not set it?

Maybe setting the permission on a non-directory fails, or something like that?

> That seems like it might be a bug in solaris?
>
> Note the 'delete_child' bit is not mentioned in the source dir?
> but that's probably a limitation of the ls version on this system:
>   > ls -lvd x
>   drwxr-xr-x   2 padraig  csw          117 Nov 26 19:05 x
>        0:user::rwx
>        1:group::r-x               #effective:r-x
>        2:mask:rwx
>        3:other:r-x

This looks like a POSIX ACL, possibly made up from the file mode.

> I see Bruno/Jim noticed issues with this "delete_child" bit previously:
> https://lists.gnu.org/archive/html/coreutils/2011-09/msg00065.html
>
> Looking at richacls on Linux I see that "delete_child"
> is implicit with the write bit:
>   $ getrichacl --long .
>   .:
>       
> owner@:list_directory/add_file/add_subdirectory/execute/delete_child::allow
>    everyone@:execute::allow

Yes.

> That suggests my patch above might be an acceptable workaround?

I'm not sure.

Thanks,
Andreas