unpack_smb_acl unknown error, + rsync maintainability

Mike Bombich mike at bombich.com
Wed Sep 2 12:53:29 MDT 2009

Oh, yeah.  Well, "it depends".  If the two machines in question share  
the same directory service, then I might want rsync to refuse to  
create an ACE with an invalid UUID.  If, OTOH, I'm backing up my home  
directory to another machine on my network and the two machines do not  
share a Directory Service, I would want it to preserve the UUID.  In  
that case, upon the restore the then-valid UUID would be properly  
restored.  Personally, I'd prefer the ACE was always preserved, and  
perhaps have a message printed that reports the error.  For example:

if (verbose > 1 && mbr_uuid_to_id(*uup, u_g_id_p, &id_type) == ENOENT)
	rprintf(FINFO, "Invalid user or group identifier in access control  
entry for %s\n", full_fname(fname));

That would give the end user the opportunity to find the erring file  
and remove the bad entry, if that's what they want to do.

 From the security perspective, the likelihood of having a UUID map to  
another (e.g. a different) valid user on the remote machine is fairly  
unlikely.  Mac OS X does have several users defined with generic UUIDs  
(e.g. _www on Snow Leopard is FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000046),  
but those are defined universally on Mac OS X, so these wouldn't  
(shouldn't) introduce conflicts.


On Sep 2, 2009, at 10:31 AM, Matt McCutchen wrote:

> On Tue, 2009-09-01 at 09:09 -0500, Mike Bombich wrote:
>> Rsync shouldn't be converting UUID to uid/gid *for ACL entries*
>> (because Mac OS X stores those ACEs with a reference to a UUID, not a
>> uid/gid).  For file ownership, etc., it should maintain its current
>> behavior.
> My point is that performing or not performing the conversion may  
> lead to
> different results if the uuid-id mapping is different on the two
> machines involved.  So the question is not just one of efficiency, but
> rather which result users are more likely to want.  I thought that  
> you,
> as a Mac user, might be able to answer that.
> -- 
> Matt

More information about the rsync mailing list