change_sacl_perms() and ACLs from Solaris to 2.6 Linux
c182driver9 at gideon.org
Tue Oct 3 01:44:07 GMT 2006
On Mon, 02 Oct 2006 20:56:34 -0400, Matt McCutchen wrote:
> Rsync expects that stat(2) on a file whose ACL contains a mask entry will
> return the mask entry as the S_IRWXG mode bits. Perhaps Solaris returns
> the group-owner entry no matter what; that would explain the trouble.
> Would you please test and see if this is the case?
If I understand what you're asking, I have looked at this. The proper
data is being sent to, and received by, the rsync running on the Linux
I displayed to stderr the ACL for the file before and after the code I
cited in change_sacl_perms(). The ACL is correct before that chunk and
wrong after that chunk.
I've found yet another problem along these lines, but it is different.
I'm copying a directory and one file within the directory. I've managed
to make the file copy have the correct ACL by changing the condition in
change_sacl_perms() to racl->mask != ACL_NO_ENTRY. However, the
directory is showing a similar symptom: the mask is being set to the
This is different, though, because it involves a second call
to set_file_attrs() for the directory. The directory's ACL is correct up
to that point. But within set_file_attrs() is a call to do_chmod() which
is apparently setting the mask of the directory incorrectly.
I'm still chasing that down, so I'm not sure. I do know that the ACL of
the directory is correct on disk before the chunk of code within
HAVE_CHMOD and wrong afterward.
There's a first call to set_file_attrs() for the directory. There's
then a call to set_file_attrs() for the file. And then there's a second
call to set_file_attrs() for the directory. Before that second call for
the directory, the directory exists and has the proper ACL. Afterward, it
has the wrong mask.
I don't know why there is a second call to set_file_attrs() for the
directory, or why it is doing something different. I also don't know how
do_chmod() (which is ACL-ignorant) is changing the mask. But as I wrote,
this one I'm still chasing.
BTW, these problems didn't exist in 2.6.2.
More information about the rsync