On 15/03/07 13:15, Giuliano Gavazzi wrote:
[...]
but when transferred back to the original machine the ACL is fine again.. so that's not so bad...
I wonder, does this mean that ACLs are stored in a machine dependent way??
AFAIK, the general principle is:
- an ACL is bound to an UUID, not a name, or a UID, or a GID
- when an UUID is generated for an object (user, group...), that
UUID is (should be) unique throughout time and space
Note that the ACL I used is:
0: user:root allow read
and root is always uid 0.
Assuming you have to boxes on which root has been assigned an UUID, root on box A is not root on box B, even if they both have the same name/UID.
Now, the root user will not always have an UUID.
This is for example the case on a OS X client on which root has never been activated and/or never logged in.
In such a case, it seems that a temporary UUID will be associated to root:
FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000000
More generally, every user without an explicit UUID will have
FFFFEEEE-DDDD-CCCC-BBBB-AAAAuuuuuuuu
as a temporary UUID, where uuuuuuuu is the user's UID.
In such cases, users on differing boxes may share a same (pseudo-)UUID and thus have "portable" ACLs.
I will try with a removable drive (or will someone else on the list do it...?)
Provided the drive is attached to a box using the directory (Netinfo, LDAP...) with the relevant info, there should be no problem.
