![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
On AIX®, UNIX®, and Linux® systems, every file (object) has three main sets of base
permissions that can either allow or restrict access by user, group or any other
user. Within each set, you have three access bits: read, write, and execute. Within these nine bits, the file can also have a set-uid, group-uid or sticky bit set.
These permissions are changeable by using the chmod
command and are generally good enough for most of the file security on the system.
However, there are situations when the standard file access does have limitations; this
can arise with application access or security related products. To overcome this, most
system administrators create groups that are related specifically to the application
that may be team or support based. However, over a period of time, the creating of
these groups with its members can become an administrative headache and rather
complex. Providing correct security on your files or directories can be troublesome.
Generally you are trying to meet a user or group needs without compromising the
security aspect of the files by allowing other users to access the said file(s).
Undoubtedly members are added to groups to satisfy applications owners that perhaps
should not really be allowed access. One method to satisfy the access authority on file access is to implement an access control list (ACL). Using ACL gives more control on who can and cannot access or execute a file or directory; that is determined by the extended permissions that can be given to a file on a user or group basis.
There are three utilities that are available to help administer ACLs:
aclput- Writes the ACL information to a file, though typically used for copying ACL definitions to another file.aclget- Display the ACL for a given file.acledit- Allows the creation and amendments of ACL to a given file within an editor.
Access control entry attributes
ACLs use access control entries (ACE) to control user and group access and denial. Though more commonly known as rules, they are:
- Permit - Grants access to a file or directory.
- Deny - Restrict access to a file or directory.
- Specify - Precisely define access to the user or group.
- With each rule, you can specify a user or group(s) to satisfy a condition before access is granted or denied.
Let's now look at a file called mig_top using aclget that
does not yet have any ACE attributes set. The basic format of the command is aclget <filename>.
# aclget mig_top
*
* ACL_type AIXC
*
attributes:
base permissions
owner(alpha): rwx
group(apps): r--
others: r--
extended permissions
disabled
|
Looking more closely at the information that aclget outputs,
the ACL_type is AIXC. The AIXC includes basic and extended permissions. The attributes
shows if the file has set-uid, group-id, or sticky bit set. The
base permissions show the permissions that are set by the chmod and chown command. The
extended permissions, if enabled, displays the extended permissions for user and
groups. If disabled, the file is treated as a normal file with base permissions only.
For the extended permissions it has the format:
Extended Permissions: ( Enabled | Disabled ) permit mode u:username,g:groupname deny mode u:username,g:groupname specify mode u:username,g:groupname |
Where:
- The Extended Permissions is either enabled or disabled.
- The rules are either permit, deny, or specify.
- The modes are read (r), write (w), or execute(x).
- User name/group name are an individual, users (u:), and/or groups (g:) separated by a comma. Each user entry must have their own rule line. You cannot combined two different users on one line.
The owner of a file can set their own ACL. A user or group can have more than one entry; this allows for further fine tuning of access. A group entry can be either single or many group names.
Let's now create an ACL on the file mig_top. Currently, it has the following permission and ownerships:
$ ls -l mig_top -rwxr--r-- 1 alpha apps 3768 Sep 30 18:11 mig_top |
As can be seen, there is no execute bit for the group, and only user alpha may execute the file. If say user bravo tries to execute the file, the following will happen:
$ id uid=210(bravo) gid=1(staff) groups=214(sun) $ /usr/local/bin/mig_top bash: /usr/local/bin/mig_top: The file access permissions do not allow the specified action. |
Let's now allow user bravo to have execute permission on that file. Using acledit, edit the file:
# acledit mig_top |
Change the extended permissions value to enabled. Then add the following entry to allow user alpha execute permission:
permit r-x u: bravo |
When the file is saved, and prior to exiting the file within acledit, you will be prompted to confirm your wish to save the changes:
Should the modified ACL be applied? (yes) or (no) yes |
Now using aclget, display the changed ACE attributes:
# aclget mig_top
*
* ACL_type AIXC
*
attributes:
base permissions
owner(alpha): rwx
group(apps): r--
others: r--
extended permissions
enabled
permit r-x u:bravo
|
Extended access is now granted to user bravo. Now, if user bravo tries to execute the file mig_top, it will succeed:
$ id uid=210(bravo) gid=1(staff) groups=214(sun) $ /usr/local/bin/mig_top now processing...wait done |
If you have syntax errors in your file when you try to save the ACL definitions, acledit displays the error found with the line number causing the
error. For example:
deny r-w u:papa
* line number 16: bad access mode: r-w
|
ACE, the rules governing extended permissions of access or denial, can be confusing. In this section, we discuss these rules and show examples on how to implement the rules. If there is a deny or specify rule in place for a user that denies access, even if the base permission gives access by user or group, the user is denied. A rule may contain multiple groups, and a user must belong to all groups for the condition to be successful. In other words, a conditional and operation is performed.
If a rule has the following:
permit r - - u:xray |
It explicitly states that user xray can only read. Write and execute is denied, unless specified by another rule. There is no need to put a deny for write and execute, it is assumed.
Also consider the following:
deny -w- u:xray
permit r-x u:xray
|
In the previous example, user xray, is denied a write, but the permit rule allows a read and execute. This operation could also be accomplished as one permit rule, like so:
permit r-x u:xray |
Looking at how a denial overrides a permit consider the following ACL:
extended permissions
enabled
permit r-x g:sun
deny r-x u:alpha
|
Members of the sun group are users alpha and bravo. There is a permit to allow members of group sun to read and execute. However, there is also a deny of read and execute for user alpha; this overrides the permit. Access for user alpha is denied.
Now consider the following:
extended permissions
enabled
permit r-x g:sun
deny r-x u:alpha,g:mobgrp
|
Now in the deny rule for alpha, the group mobgrp has been added. This states that if user alpha belongs to the group mobgrp, then user alpha is also denied. If user alpha does not belong to the group mobgrp, access for user alpha is granted.
In the next example, read and write permission has been granted for the groups sun and mobgrp. Only users who are members of both groups will be granted read, write to the file.
extended permissions
enabled
permit rw- g:sun,g:mobgrp
|
The following is a more populated ACL, combining different rules for users and groups:
attributes:
base permissions
owner(root): rwx
group(system): r--
others: ---
extended permissions
enabled
specify rw- u:xray,g:chatt
permit rw- g:sun,g:mobgrp
permit rw- u:alpha,g:sun,g:earth
permit rw- u:juliet
deny rw- u:bravo,g:mobgrp,g:apps,g:syb
deny -w- u:xray,g:chatt,g:spyi
|
In this output, none of the users or groups have base permissions to allow read, write, or execute.
The first rule specifies that user xray will override the base permissions for read and write access, as long as he is a member of the group chatt. If this condition is not met, then read and write access is denied.
The second rule permits the users who belong to both groups, sun and mobgrp, to have read and write access. If this condition is not met, then permit access is denied.
The third rule permits user alpha read and write access, if user alpha is a member of both groups, sun and earth. If this condition is not met, access is denied.
The fourth rule permits read access to user juliet. There are no conditions set for user juliet for this to be denied.
The fifth rule denies user bravo read and write access if user bravo is a member of all these groups: mobgrp and apps and syb. If this condition is not met access is granted.
The sixth rule denies write access to user xray if user xray is a member of groups chatt and spyi. If this condition is not met, access is denied. However, if he is only a member of the group chatt, then the first rule applies, and the specified read access is granted.
Though I have just demonstrated ACL on files, they can also be used on directories. The same principles apply.
A question that often crops up in forums is how to disable su to certain users. Using ACL, it is quite easy to fine
tune permissions with users who are allowed to use the su
command. Looking at one example, assume we had some user accounts where the default
policy is that they do not have the ability to su to other
accounts, even if they know the password. One solution is to use sudo with su, but first you must restrict
them using su. Imagine if the list of users whom we did not
want to use su were golf, hotel and india. For these users,
first create a group. Let's call it, nosu:
# mkgroup -A users="golf,hotel,india" nosu # lsgroup nosu nosu id=219 admin=false users=golf,hotel,india adms=root registry=files |
Next, using acledit enable the extended permissions and add
the group nosu to read and execute deny to the su binary file. Use aclget to confirm changes are in place after editing:
# aclget /usr/bin/su
*
* ACL_type AIXC
*
attributes: SUID
base permissions
owner(root): r-x
group(security): r-x
others: r-x
extended permissions
enabled
deny r-x g:nosu
|
Now if the group members of nosu try to su, they are refused:
$ id uid=224(india) gid=1(staff) groups=207(fire),208(cloud),217(nossh),219(nosu) $ su - alpha ksh: su: 0403-006 Execute permission denied. |
To allow su access on an adhoc basic for those accounts, use sudo. The following example shows the sudoers entry required to let the group nosu have su access to the user zulu on local host rs6000:
%nosu rs6000 = NOPASSWD:/usr/bin/su – zulu |
Now user india, who is a nosu group member, can su to zulu via sudo:
$ id
uid=224(india) gid=1(staff) groups=207(fire),208(cloud),217(nossh),219(nosu)
$ sudo -l
User india may run the following commands on this host:
(root) NOPASSWD: /usr/bin/su - zulu
$ sudo -u root su - zulu
$ id
uid=228(zulu) gid=1(staff) groups=209(earth)
|
To copy ACL information from one file to another, use aclget
with a pipe to aclput. For example, to copy the ACL information from mig_top to the file prop_krb_admin, I could use:
# aclget mig_top | aclput prop_krb_admin |
To copy ACL information to many files, I suggest first copying the ACL information into
a template file, where you can then edit this file with vi to tweak the file security
permissions based on your own security policy. Once done, use aclput to put the ACL definition into the files you wish to copy in the ACL attributes.
For example, to extract the ACL definition from the file mig_top into a template file called default_acl, use:
# aclget -o default_acl mig_top |
Then using aclput, copy the definitions contained in the file default_acl into the (existing) file prop_krb_admin use:
# aclput -i default_acl prop_krb_admin |
Confirm the copy of the ACL has taken place:
# aclget prop_krb_admin * ACL_type AIXC * attributes: base permissions owner(root): rwx group(system): r-- others: r-- extended permissions enabled permit r-x g:admin,g:sysmaint |
If you are going to process a large amount of files, I suggest creating a script that iterates the files to change.
How do I know if I have ACL on a file
When an ACL is enabled on a file, the 11th bit will be a '+' sign. Use the 'U' flag with the ls command to list files that have ACL on them:
$ ls -Ul probe_sys* -r-xr-xr--+ 1 root operator 25 Aug 17 11:24 probe_sys -rwxr-x---- 1 operator operator 24 Jul 1 17:24 probe_sys.sh |
In this example, we see that the file probe_sys has ACL enabled on that file but probe_sys.sh does not.
You can also use the find command with the 'ea' option to find files that are ACL enabled, like so:
# find. -ea ./probe_sys ./admin_list.sh ./cont_del.sh |
When experiencing problems with ACL enabled files, re-check that your rules are
correct. Be sure to first check for any deny rule, as this overrides other rules to the user/group you have specified. I suggest using truss to further diagnose the issue.
As the user, issue the truss command. In the following
example, truss is issued against the mig_top file where access permissions are being experienced:
$ truss /usr/local/bin/mig_top |
If a lot of output is generated, simply redirect it to a file for further diagnostics. Within the output, look out for the pattern containing "Err". Going through the output will hopefully tell you where the issues are.
430292: execve("/usr/local/bin/mig_top", 0x2001ECB8, 0x2001EA48) Err#13 EACCES
430292: statx("/usr/local/bin/mig_top", 0x2FF228C0, 128, 010)= 0
430292: statx("/usr/local/bin/mig_top", 0x2FF22770, 128, 010) = 0
430292: open("/usr/local/bin/mig_top", O_RDONLY|O_LARGEFILE) Err#13 EACCES
|
If the truss cannot be ran by a non-root user for some
reason, user root can monitor that user's activity via a truss session. As root, get the PID of the user having
issues. This can be achieved by the user issuing:
$ echo $$ 212996 |
Then as root, issue the truss command supplying the PID of
the users process. Next, ask the user to access the file that is proving problematic.
# truss -aef -p 212996 |
From roots terminal session, view the output to help you diagnose the issues.
Using ACLs can aid in your file security by fine tuning access permissions, based on group membership, combined group membership, or by specific user(s) only.
Learn
- See access
control list for additional information.
Discuss
- Follow developerWorks on Twitter.
- Get involved in the My developerWorks community.
-
Participate in the AIX and UNIX® forums:
- AIX Forum
- AIX Forum for developers
- Cluster Systems Management
- Performance Tools Forum
- Virtualization Forum
- More AIX and UNIX Forums
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
