Default ACL: Semantics (again)

[James Buster]

On Oct 7,  2:00am, Andreas Gruenbacher wrote:
} The mode field of the file has to be initialized in a meaningful way.
} 
} For the owner, there are:
} (A) the ACL_USER_OBJ ACL entry permission bits.
} (B) the user bits in the mode field of the file.
} 
} So my understanding of the standard is:
} Set both (A) and (B) to the intersection of the default ACL's
} ACL_USER_OBJ entry permission bits and the ACL_MASK entry
} permission bits.
} 
} Correct? Unclear? Wrong?

Wrong. The ACL_MASK entry doesn't affect ACL_USER_OBJ or ACL_USER
entries. From section 23.1.4, Associating an ACL with an Object at
Object Creation Time:

    Both the ACL_USER_OBJ ACL entry permission bits and the file owner
    class permission bits are set to the intersection of the default
    ACL's ACL_USER_OBJ permission bits and the file owner class permission
    bits in the mode parameter.

ACL_USER entries aren't mentioned at all, so they are copied unchanged
to the access ACL.

} Now the old question was why the permissions joe would
} have from the `u:joe:rwx' entry shouldn't get added to the
} `user::---' entry.

Because it was considered consistent with POSIX.1 semantics,
in particular the fact that while a process may have multiple
supplementary groups, it only ever has one user id and therefore
only ever needs one matching ACL entry.

-- 
Planet Bog -- pools of toxic chemicals bubble under a choking
atomsphere of poisonous gases... but aside from that, it's not
much like Earth.
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message