An ACE is defined by a combination of user, group, or role definitions. You can combine these definitions using the following syntax:
|u||Username or user ID, as they appear in |
|g||Group name or group ID, as they appear in /etc/group, of a specific group. Usage: |
|r||Name of a specific role. Usage: |
|p||Public. Specifies that this operation is available to the public without restriction. Cannot be combined with any other operator.|
|!||Negation operator. Usage: |
|()||Delimiters for subexpressions.|
|""||The empty string indicates that no user has the specified permission.|
An example definition is
u:1001 | r:engineering, which restricts access to the user with ID 1001 or to any user with the role
In this next example, members of the group
admin are given access, and so are members of the group
g:admin | g:qa
For another example, suppose that you have this list of groups to which you want to give read permissions on a table:
admingroup as a whole, but not the admins for a particular cluster (which is named
Members of the
qagroup who are responsible for testing the two applications (named
app3) that access this table.
The business analysts (group
ba) in department 7A (group
All of the data scientists (group
ds) in the company.
To grant the read permission, you construct this boolean expression:
u:cfkane | (g:admin & !g:cl3) | (g:qa & (g:app2 | g:app3)) | (g:ba & g:dept_7a) | g:ds
This expression is made up of five subexpressions which are separated by OR operators.
- The first subexpression
u:cfkanegrants the read permission to the username
(g:admin & !g:cl3)grants the read permission to the admins for all clusters except cluster
cl3. The operator
gis the group operator, the value
adminis the name of the group of all admins. The
&operator limits the number of administrators who have read permission because only those administrators who meet the additional condition will have it.
The condition !
g:cl3is a limiting condition. The operator
!is the NOT operator. Combined with the group operator, this operator means that this group is excluded and does not receive the read permission.
Be careful when using the NOT operator. You might exclude fewer people than you intended. For example, suppose that you do not want anyone in the group
group_ato have access. You therefore define this ACE:
You might think that the data in your table is now protected because members of
group_ado not have access to it. However, you have not restricted access for anyone else except the members of
group_a. The rest of the world can access the table.
You should not define ACEs through exclusion by using the NOT operator. You should define them by inclusion and use the NOT operator to limit further the access of the groups or roles that you have included.
In the subexpression
(g:admin & !g:cl3), the NOT operator limits the number of members within the admin group who have access. The
admingroup is included, and all users who are also part of the
cl3group are excluded.
- The first subexpression
(g:qa & (g:app2 | g:app3))demonstrates that you can use a subexpression within a subexpression. The larger subexpression means that only members of group
qawho are also members of group
app3have read access to the table. The smaller subexpression limits the number of people in the
qagroup have have this permission.
The next two subexpressions --
(g:ba & g:dept_7a)and
g:ds-- grant the read permission to the members of group
bawho are also in the group
dept_7a. It also grants permission to the members of the group