Understanding swacl

A typical acl_file looks like this:

# swacl    Installed Software Access Control List
#
# For host:  prewd:/
#
# Date:  Wed May 19 16:39:58 1993
#
# Object Ownership: User=root
                    Group=sys
                    Realm=prewd.fc.hp.com
# default_realm=prewd.fc.hp.com
object_owner:crwit
user:rml:crwit
user:root@newdist.fc.hp.com:crwit
group:swadm:crwit
any_other:crwit

The header information (lines marked with #) gives the object's name and owner and the name of the user's realm or host name of his/her system.

The swacl command, when invoked without the -M, -D or -F options, reads the specified ACL, converts it into plain text and prints it to the screen so you can see it. If you re-direct the output of the command to a file, you can then edit that file and change the permissions in it. After editing, you can use the -F file option described above to replace the old ACL. This procedure gives you full ACL editing capabilities.

You must have "test" permission within the ACL to produce the edit file (list the ACL) and "control" permission to change it with -F, -D or -M options.

If the replacement ACL contains no detectable errors and you have the proper permission on the ACL, the replacement succeeds. If the replacement fails because you lack permission to make the change, an error is generated and the object is skipped.

You may change or delete existing entries, or you may add additional entries to the ACL.

	CAUTION: It is possible to edit an ACL so that you cannot access it! Caution should be used to avoid accidentally removing your own control (c) permissions on an ACL. As a safeguard, the local superuser should always edit ACLs.

How ACLs are Matched to the User

It is important to note that permissions in ACLs are determined by a match to a single ACL entry (except for group entries), not to an accumulation of matching entries. Simply put, checking is done from the most restrictive entry types to the broadest. If a match is found in a user entry type, no further checking is done, and the permissions for that user are fully defined by the permissions field of the matched entry. That the matched user may be a member of a group with broader permissions is of no consequence.

	NOTE: The local host superuser has access to all local objects, irrespective of ACLs.

The ACL matching algorithm is:

1. If user is local superuser, then grant all permissions, else

2. If user is owner of the object, then grant "object_owner" permissions, else

3. If user matches a "user" entry, then grant "user" permissions, else

4. If any "group" entries match, then accumulate the permissions granted by all group_entries that match the user's primary and supplementary groups, else

5. If an appropriate "other" entry matches, then grant "other" permissions, else

6. If an "any_other" entry, then grant "any_other" permissions, else

7. Grant no permissions