2016-11-26 23:00 GMT+01:00 Pádraig Brady <[email protected]>: > 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
