HP-UX Reference (11i v1 00/12) - 5 Miscellaneous Topics, 7 Device (Special) Files, 9 General Information, Index (vol 9)

__________________________________________________________________________________________________________________________________________________________________________________________________
__________________________________________________________________________________________________________________________________________________________________________________________________
STANDARD Printed by: Nora Chuang [nchuang] STANDARD
/build/1111/BRICK/man5/!!!intro.5
________________________________________________________________
___ ___
a
acl(5) acl(5)
chown If the new owner and/or group of a file does not already have an optional (u.%, mode) and/or (%.g,
mode) entry in the file’s ACL, it inherits the old owner’s and/or group’s file access permission bits
and base ACL entry:
(id1,mode1)->(id2,mode1)
This is the traditional behavior. However, if the new owner and/or group of a file already has an
optional (u.%, mode)and/or(%.g, mode) entry in the file’s ACL, the ACL does not change:
(id1, mode1)->(id1, mode1)
(id2, mode2)->(id2, mode2)
Existing access information in the ACL is preserved. However, because the old optional ACL entry
becomes the new base ACL entry and vice versa, the file’s access permission bits change.
Transferring ownership of ACLsbychown(2) allows a file to be transferred to a different user or
group, or copied by a different user or group than the owner (using cpacl(3C) or chownacl(3C)),
and later returned to the original owner or group without net changes to its ACL. The extra com-
plexity is necessary because:
• ACLs are a backward-compatible superset of permission bits (which are coupled to file owner
and group IDs), not a replacement for them.
• it enables users and programs that deal with ACLs to do so simply, rather than with a combi-
nation of permission bits and ACL entries. Also, the access check algorithm is simpler and
more symmetrical; permission bits do not ‘‘eclipse’’ or ‘‘mask’’
ACL entries.
EXAMPLES
Operator Form
The following sets the %.% entry to restrict ‘‘other’’ users to only reading the file.
chacl ’%.% = r’ myfile
The following allows user ‘‘bill’’ in any group to write the file, assuming that no restrictive entry is more
specific than the bill.% entry (for example, a bill.adm entry that denies writing).
chacl ’bill.% +w’ myfile
The following
ACL specification contains two entries. The first one deletes write and adds read capability to
the entry for user 12, group 4. The second entry denies access for any unspecified user in any unspecified
group.
chacl ’12.4-w+r, %.% =’ myfile
The following pair of entries sets the u.% entry for the file’s owner to allow both read and execute and
results in adding write and execute capabilities for ‘‘other’’ users (the ‘‘%.%’’ entry). Note that a mode char-
acter is purposely repeated for illustration purposes.
chacl ’@.% = 5, %.% + xwx’ myfile
Short Form
Here is a typical ACL as it might be printed. It allows user jpc to read or execute the file while in group
adm; it denies user ajs access to the file while in group trux; it allows user jpc in any group (except adm)
to only read the file; any other user in group bin may read or execute the file; and any other user may only
read the file.
(jpc.adm,r-x)(ajs.trux,---)(jpc.%,r--)(%.bin,r-x)(%.%,r--)
The following allows ‘‘other’’ users to only read the file.
chacl ’(%.%,r)’ myfile
The following sets write-only access for user bill in any group.
chacl ’(bill.%,-w-)’ myfile
The following sets the entry for user 12 in group 4 to allow read and write.
chacl ’(12.4,wr)’ myfile
The following sets the base ACL entry for the file’s owner to allow both read and execute, and sets write
and execute capabilities for ‘‘other’’ users (the ‘‘%.%’’ entry).
HP-UX Release 11i: December 2000 − 6 − Section 5−−7
___
___