En­joy Bet­ter Flex­i­bil­ity in Grant­ing File Sys­tem Per­mis­sions with Ac­cess Con­trol Lists (ACLs)

ACLs pro­vide ad­di­tional and more flex­i­ble per­mis­sions for file sys­tems. They give bet­ter con­trol over who can read, write and ex­e­cute a file or any disk re­source.

OpenSource For You - - Contents - By: Kshi­tij Upad­hyay The au­thor is RHCSA and RHCE cer­ti­fied, and loves to write about new tech­nolo­gies. He can be reached at upad­[email protected]

Stan­dard Linux file per­mis­sions are sat­is­fac­tory for most sit­u­a­tions but they have their lim­i­ta­tions. Per­mis­sions can be set to re­strict ac­cess to a file to only the file owner, to mem­bers of a sin­gle group, or to ev­ery­one else. It may not be ap­pro­pri­ate for the process (a run­ning pro­gram) to be a mem­ber of the group own­ing the files, and even less de­sir­able to grant per­mis­sion to ev­ery­one.

ACLs al­low fine-grained per­mis­sions to be al­lo­cated to a file. Named users or named groups, as well as users and groups iden­ti­fied by a UID or GUID, can be granted per­mis­sions, in ad­di­tion to the stan­dard file owner, group owner and other file per­mis­sions. The same per­mis­sion flags ap­ply: r – read, w – write, and x – ex­e­cute (on files, search for di­rec­to­ries).

The file owner can set ACLs on in­di­vid­ual files or di­rec­to­ries. New files and sub-di­rec­to­ries can au­to­mat­i­cally in­herit ACL set­tings from the par­ent di­rec­tory’s de­fault ACLs, if they are set. Just like nor­mal file ac­cess rules, the par­ent di­rec­tory hi­er­ar­chy will need at least the other ex­e­cute per­mis­sion set to en­able named users and named groups to have ac­cess.

The file sys­tem mount op­tion

The file sys­tem needs to be mounted with ACL sup­port en­abled. XFS file sys­tems have built-in ACL sup­port. Ext4 file sys­tems cre­ated on Red Hat En­ter­prise Linux 7 (RHEL 7) have the ACL op­tion en­abled by de­fault, but ext4 file sys­tems cre­ated in ear­lier ver­sions of RHEL may need the ACL op­tion

in­cluded with the mount re­quest, or set in the su­perblock.

View­ing and in­ter­pret­ing ACL per­mis­sions

The ls-l com­mand only out­puts min­i­mal set­ting de­tails.

The + at the end of a 10-char­ac­ter per­mis­sion string in­di­cates that there are ACL set­tings as­so­ci­ated with this file. You can in­ter­pret the user, group and other rwx flags as fol­lows.

User: Shows the user ACL set­tings, which are the same as stan­dard user file set­tings; rwx.

Group: Shows the cur­rent ACL mask set­tings, not the group owner set­tings; rw.

Other: Shows the other ACL set­tings, which are the same as other stan­dard file set­tings; no ac­cess.

Note: Chang­ing group per­mis­sions on a file with an ACL by us­ing chmod does not change the group owner per­mis­sions and does not change the ACL mask. Use the set­facl –m g::perms file if the in­tent is to update the file group owner per­mis­sions.

View­ing the ACLs

To dis­play ACL set­tings on a file, use get­facl file name (Fig­ure 2).

Each sec­tion of the ex­am­ple given in Fig­ure 2 in­di­cates the fol­low­ing.

Open­ing com­ment en­tries: The first three lines are com­ments that iden­tify the file name, owner (stu­dent) and group owner (con­troller). If there are any ad­di­tional file flags, for ex­am­ple, se­tuid or set­gid, then a fourth com­ment line will ap­pear show­ing which flags are set.

User en­tries:

1. File owner per­mis­sion is rwx.

2. The named user is ram and abc per­mis­sions are rwx.

Group en­tries:

1. Group owner per­mis­sions are rw-.

2. Named group per­mis­sions. One en­try for the group pqr shows per­mis­sion to be rwx.

View­ing di­rec­tory ACLs

To dis­play ACL set­tings on a di­rec­tory, you can use get­facl / di­rec­tory (Fig­ure 3).

Each sec­tion of the ex­am­ple given in Fig­ure 3 in­di­cates the fol­low­ing.

Open­ing com­ment en­tries: The first three lines of com­ments iden­tify the di­rec­tory name, the owner (stu­dent), and group owner (con­troller). If there are any ad­di­tional di­rec­tory flags (se­tuid, set­gid, sticky), then a fourth com­ment line will ap­pear show­ing the set flags—in this case, set­gid.

Stan­dard ACL en­tries which are shown below the com­ment lines are the ACL per­mis­sions on this di­rec­tory. They are the same as the file ex­am­ple men­tioned ear­lier, but ap­ply to the di­rec­tory. The key dif­fer­ence is the in­clu­sion of the ex­e­cute per­mis­sion on these en­tries (when ap­pro­pri­ate) to al­low di­rec­tory search per­mis­sion.

The ACL mask

The ACL mask de­fines the max­i­mum per­mis­sions that can be gen­er­ated for named users, the group owner and named groups. It does not re­strict the per­mis­sions of the file owner or other users. All files and di­rec­to­ries that im­ple­ment ACLs will have an ACL mask.

The mask can be viewed with get­facl and can be ex­plic­itly set with set­facl. It will be cal­cu­lated and added au­to­mat­i­cally if it is not ex­plic­itly set, but it could also be in­her­ited from a par­ent di­rec­tory’s de­fault mask set­ting. By de­fault, the mask is re­cal­cu­lated when­ever any of the af­fected ACLs are added, mod­i­fied or deleted.

ACL per­mis­sion prece­dence

When de­ter­min­ing whether a process (a run­ning pro­gram) can ac­cess a file, file per­mis­sions and ACLs are ap­plied as fol­lows:

If a process is run­ning as the user that owns the file, then the file’s user ACL per­mis­sions ap­ply.

If the process is run­ning as a user that is listed in a named user ACL en­try, then the named user ACL per­mis­sions ap­ply (as long as it is per­mit­ted by the mask).

If the process is run­ning as a group that matches the group owner of the file or as a group with an ex­plicit name group ACL en­try, then the match­ing ACL per­mis­sions ap­ply (as long as it is per­mit­ted by the mask).

Oth­er­wise, the file’s other ACL per­mis­sions ap­ply.

Se­cur­ing files with ACLs

Chang­ing ACL file per­mis­sions: Use set­facl to add, mod­ify or re­move stan­dard ACLs on files and di­rec­to­ries. ACLs use the nor­mal file sys­tem rep­re­sen­ta­tion r for read per­mis­sion, w for write per­mis­sion, and x for ex­e­cute per­mis­sion. A ‘-’ (dash) in­di­cates that the rel­e­vant per­mis­sion is ab­sent. When (re­cur­sively) set­ting ACLs, an up­per-case X can be used to in­di­cate that ex­e­cute per­mis­sions should only be set on di­rec­to­ries and not reg­u­lar files, un­less the file al­ready has the rel­e­vant ex­e­cute per­mis­sions. This is the same be­hav­iour as chmod.

Adding or mod­i­fy­ing an ACL: ACLs can be set via the com­mand line us­ing –m or passed via a file us­ing –M (use

‘-’ (dash) in­stead of a file name for stdin). These two are the mod­ify op­tions; they add new ACL en­tries or re­place spe­cific ex­ist­ing ACL en­tries on a file or di­rec­tory. Any other ex­ist­ing ACL en­tries on the file or di­rec­tory re­main un­touched. To add or mod­ify a user or named user ACL, use the fol­low­ing com­mand:

# set­facl –m u:name:rX file

If a name is left blank, then it ap­plies to the file owner; oth­er­wise, the name can be a user name or UID value. In this ex­am­ple, the per­mis­sions granted are read-only and if al­ready set, ex­e­cute (un­less the file was a di­rec­tory, in which case the di­rec­tory gets the ex­e­cute per­mis­sions set to al­low di­rec­tory search).

ACL file owner and stan­dard file owner per­mis­sions are equiv­a­lent; con­se­quently, us­ing chmod on the file owner per­mis­sions is equiv­a­lent to us­ing set­facl on them. chmod has no ef­fect on named users.

To add or mod­ify a group or named group ACL, use the fol­low­ing com­mand:

# set­facl –m g:name:rw file

This fol­lows the same pat­tern for adding or mod­i­fy­ing a user ACL. If the name is left blank, then it ap­plies to the group owner. Oth­er­wise, spec­ify a group name or GID value for a named group. The per­mis­sions are read and write in this ex­am­ple. chmod has no ef­fect on any group per­mis­sions for files with ACL set­tings, but it up­dates the ACL mask.

To add or mod­ify the other ACL, use the fol­low­ing com­mand:

#set­facl –m o::- file

Other only ac­cepts per­mis­sion set­tings. It is com­mon for per­mis­sions to be set to ‘-’ (dash), which spec­i­fies that other users have no per­mis­sions, but any of the stan­dard per­mis­sions can be spec­i­fied.

ACL other and stan­dard other per­mis­sions are equiv­a­lent, so us­ing chmod on the other per­mis­sions is equiv­a­lent to us­ing set­facl on them. Add mul­ti­ple en­tries us­ing the same com­mand, and comma-sep­a­rate each of the en­tries, as fol­lows:

# set­facl –m u::rwx, g:sodor:rX,o::- file

This will set the file owner to read, write and ex­e­cute; set the named group sodor to read-only and con­di­tional ex­e­cute, and re­strict all other users to no per­mis­sions. The group owner will main­tain the ex­ist­ing file or ACL per­mis­sions and other named en­tries will re­main un­changed.

Us­ing get­facl as in­put

The out­put from get­facl can be used as in­put to set­facl: # get­facl file-A | set­facl --set-file=- file-B

-set-file ac­cepts in­put from a file or stdin and the ‘-’ (dash) spec­i­fies the use of stdin. In this case, File B will have the same ACL set­tings as File A.

Set­ting an ex­plicit ACL mask

An ACL mask can be ex­plic­itly set on a file or di­rec­tory to limit the max­i­mum ef­fec­tive per­mis­sions for named users, the group owner, and named groups. This re­stricts any ex­ist­ing per­mis­sions that ex­ceed the mask, but does noth­ing to per­mis­sions that are less per­mis­sive than the mask.

# set­facl –m m: :r file

This adds a mask value that re­stricts any named users, the group owner and any named groups to read-only per­mis­sion, re­gard­less of their ex­ist­ing set­tings. The file owner and other users are not im­pacted by the mask set­ting. get­facl will show an ‘ef­fec­tive’ com­ment be­side en­tries that are be­ing re­stricted by a mask set­ting.

Note: By de­fault, the ACL mask is re­cal­cu­lated each time one of the im­pacted ACL set­tings (named users, group owner, or named groups) is mod­i­fied or deleted, po­ten­tially re­set­ting a pre­vi­ous ex­plicit mask set­ting. To avoid mask re­cal­cu­la­tions, use –n or in­clude a mask set­ting (-m m::perms) with any set­facl op­er­a­tion that mod­i­fies maskaf­fected ACL set­tings.

Re­cur­sive ACL mod­i­fi­ca­tions

When set­ting an ACL on a di­rec­tory, it is com­mon to want to ap­ply the ACL re­cur­sively to the di­rec­tory struc­ture and files. Use the –R op­tion to do this. The X (up­per case X) per­mis­sion is of­ten used with re­cur­sion, so that files with the ex­e­cute per­mis­sions set re­tain the set­ting, and di­rec­to­ries get the ex­e­cute per­mis­sions set to al­low di­rec­tory search. It is con­sid­ered good prac­tice to also use the up­per­case X when non-re­cur­sively set­ting ACLs, as it pre­vents an ad­min­is­tra­tor from ac­ci­den­tally adding ex­e­cute per­mis­sions to a reg­u­lar file.

# set­facl –x u:name, g:name file

This only re­moves the named user and the named group from the list of file or di­rec­tory ACLs. Any other ex­ist­ing ACLs re­main ac­tive.

It is pos­si­ble to use the delete (-x) and mod­ify (-m) op­er­a­tions in the same set­facl op­er­a­tion.

The mask can only be deleted if there are no other ACLs set (ex­clud­ing the base ACLs which can­not be deleted), so it must be deleted last. The file will no longer have ACLs and ls-l will not show the ‘+’ sym­bol next to the per­mis­sions string. Al­ter­na­tively, to delete all ACLs on a file or di­rec­tory (in­clud­ing de­fault ACLs on di­rec­to­ries), use the fol­low­ing com­mand: # set­facl –b file

Con­trol­ling de­fault ACL file per­mis­sions

A di­rec­tory can have de­fault ACLs set on it that are au­to­mat­i­cally in­her­ited by all new files and new sub­di­rec­to­ries. There can be de­fault ACL per­mis­sions set for each of the stan­dard ACL set­tings, in­clud­ing a de­fault mask.

A di­rec­tory still re­quires stan­dard ACLs for ac­cess con­trol be­cause de­fault ACLs do not im­ple­ment ac­cess con­trol for the di­rec­tory—they only pro­vide ACL per­mis­sion in­her­i­tance sup­port.

Here is an ex­am­ple:

# set­facl –m d:u:name:rx di­rec­tory

This adds a de­fault named user (d:u:name) with read-only per­mis­sion and ex­e­cute per­mis­sion on sub-di­rec­to­ries.

The set­facl com­mand for adding a de­fault ACL for each of the ACL types is ex­actly the same as for stan­dard ACLs, but pref­aced with d:. Al­ter­na­tively, use the –d op­tion on the com­mand line.

Im­por­tant: When set­ting de­fault ACLs on a di­rec­tory, en­sure that users will be able to ac­cess the con­tents of new sub-di­rec­to­ries cre­ated in it by in­clud­ing the ex­e­cute per­mis­sions on the de­fault ACL. Users will not au­to­mat­i­cally get the ex­e­cute per­mis­sions set on newly cre­ated reg­u­lar files be­cause, un­like new di­rec­to­ries, the ACL mask of a new reg­u­lar file is rw-.

Note: New files and new di­rec­to­ries con­tinue to get their owner UID and pri­mary group GID val­ues set from the cre­at­ing user, ex­cept when the par­ent di­rec­tory set­gid flag is en­abled, in which case the pri­mary group GID will be the same as the par­ent di­rec­tory GID.

Delet­ing de­fault ACLs

The process for delet­ing a de­fault ACL is also the same as for delet­ing a stan­dard ACL; again, pref­ace with d: or use the –d op­tion.

# set­facl –x d:u:name di­rec­tory

This re­moves the de­fault ACL that has been added in the pre­vi­ous ex­am­ple. To delete all de­fault ACLs on a di­rec­tory, use set­facl –k /di­rec­tory. To delete all ACLs on a di­rec­tory, use set­facl –b /di­rec­tory.

Fig­ure 2: ACL set­tings on the file osfy.txt

Fig­ure 3: ACL on a di­rec­tory

Fig­ure 1: The ‘+’ in­di­cates the pres­ence of ACL

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.