Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
> From: cvsnt-bounces at cvsnt.org > [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Oliver Koltermann > Sent: Friday, 28 April, 2006 09:30 > > after reading the corresponding manual page for CVSNT (shame on me!) I > realized, that my description does not completely fit the CVSNT's ACL > scheme. Different from *nix ACL there is a special create permission > for the directory and the read/write permissions are indeed for the > contained files. The manual states the following: > > "For a user to have access to a directory, they must have at least > read access to all the directories above it. If a user has a 'no > access' ACL on a parent directory they cannot be granted access to > directories below it." Part of the problem here seems to be confusion between traditional Unix file permissions, which are NOT an ACL mechanism, and the ACL facilities available in some Unix filesystems (eg AFS) and enhanced kernels. The latter are much more like Windows ACLs or CVSNT ACLs. Under traditional Unix file permissions, write access to the directory gives a user precisely what it sounds like: the ability to update the directory. That includes creating a file, or removing a directory entry and its associated hard link. (If the last hard link to a file is removed, then the file will be deleted when there are no more open descriptors for it.) Traditional Unix file permissions aren't an ACL mechanism because they provide a fixed, three-level hierarchy of actors and actions. ACLs by definition are arbitrary lists of actor-action-permission relationships, so they're more flexible and complex than Unix file permissions. -- Michael Wojcik Principal Software Systems Developer, Micro Focus