|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| Operations | Random Findings | Etc |
|
|
Contents
Peter Gavlin. Controlling ACLs - SunWorld - August 1996 by Peter Galvin
Controlling permissions with ACLs - SunWorld - June 1998 by Jim Mauro
[Duke University] Using Solaris ACLs
Sys Admin Magazine Achieving More Flexible File Permissions Using Solaris ACLs by Ross Oliver
POSIX Access Control Lists on Linux by Andreas Grünbacher
|
|
[Gavlin1996] Controlling ACLs - SunWorld - August 1996 by Peter Galvin
[Mauro1998] Controlling permissions with ACLs - SunWorld - June 1998 by Jim Mauro
File security in Solaris has up until recently been limited to the file mode bits that provide the traditional coarse-grained levels of protection. This month, we'll look at how access control lists are used and implemented in the Solaris kernel. (2,800 words)
The format for a file ACL is two or three columns separated by a colon:
entry_type:[uid|gid]:perms
The first column, entry_type, defines the ACL entry as set for the user, group, other or an ACL mask. The second column is (optionally) the user ID (UID) or username for user entry types, or group ID (GID) or groupname for group entry types. For entry types other and mask, this column does not apply and thus is not required. The third column is for file permissions. File permissions take either the familiar rwx (read/write/execute) symbolic form, or the numeric form in octal notation (e.g., 7 for rwx, 4 for r--, 6 for rw-, etc.), both of which are exactly identical to the format used for chmod(1). The internal representation as a data structure looks like this (from /usr/include/sys/acl.h):
typedef struct acl { int a_type; /* entry type */ uid_t a_id; /* UID | GID */ o_mode_t a_perm; /* permissions */ } aclent_t;Each field in the above data structure corresponds to the ACL entry described above.
When the optional username (or UID) for a user entry type is excluded, and the groupname (or GID) for a group entry is empty, the traditional Solaris file permissions are being applied (we'll illustrate this in the example below).
Users set, modify, and delete ACLs using setfacl(1) and examine file ACLs using getfacl(1). The quick example below illustrates the use of file ACLs. The left hand column is numbered to provide a reference for the description that will follow.
1 sunsys> ls -l file1 2 -rwxr-xr-- 1 jim staff 130 May 25 22:13 file1 3 sunsys> chmod 000 file1 4 sunsys> ls -l file1 5 ---------- 1 jim staff 130 May 25 22:13 file1 6 sunsys> setfacl -s user::rw-,group::r--,other:r-- file1 7 sunsys> ls -l file1 8 -rw-r--r-- 1 jim staff 130 May 25 22:13 file1 9 sunsys> getfacl file1 10 # file: file1 11 # owner: jim 12 # group: staff 13 user::rw- 14 group::r-- #effective:r-- 15 mask:r-- 16 other:r-- 17 sunsys> setfacl -m user:moe:rw- file1 18 sunsys> ls -l file1 19 -rw-r--r--+ 1 jim staff 130 May 25 22:13 file1 20 sunsys> getfacl file1 21 # file: file1 22 # owner: jim 23 # group: staff 24 user::rw- 25 user:moe:rw- #effective:r-- 26 group::r-- #effective:r-- 27 mask:r-- 28 other:r--We first did a long listing of a file called file1 and set all mode bits to zero with chmod(1) (lines 1-5). Line 6 shows the setfacl(1) command with the -s flag, which is the set acl flag. The setfacl(1) command executed on line 6 does not define special permissions for a particular user or group. It is essentially the equivalent of executing a chmod 644 file command on the same file.
The long listing on line 7 shows that we now have established file permissions that are reflected in the file mode bits. Using getfacl(1) (line 9), we display the file permissions in ACL format. Now, at this point, we technically do not have an ACL for this file. The Solaris kernel looks at the ACLs being set, and for simple cases where the setfacl(1) command is simply establishing the traditional file permissions for user, group, and other, an actual ACL is not allocated for the file. The kernel applies the permissions defined in the setfacl(1) command line to the file mode field in the inode.
On line 17 we establish read/write permissions for user Moe, using the m (modify) flag with setfacl(1). The subsequent long listing (line 18) and examination of the file ACL (line 20) reveal something interesting. On line 19, note the plus (+) sign at the end of the file modes. This tells us that an ACL exists for the file (the plus sign was absent from the listing on line 8). Now when we run the getfacl(1) command (line 20), we see the addition of the user: moe entry in the ACL.
There are a few worthwhile points on the behavior of ACLs and the rules of precedence. The example above shows an ACL mask of r--. The ACL mask defines the maximum permissions allowed for everyone except the owner of the file; in this example, everyone except the file owner has read-only permission. However, the ACL has defined read and write permissions for Moe. So what will happen if Moe attempts to write to the file -- which will take precedence, his special permissions, or the ACL mask? The answer is, the ACL mask. Here's another quick example.
1 sunsys> getfacl file1 2 # file: file1 3 # owner: jim 4 # group: staff 5 user::rw- 6 user:moe:rw- #effective:r-- 7 group::r-- #effective:r-- 8 mask:r-- 9 other:r-- 10 sunsys> su moe 11 Password: 12 $ id 13 uid=2001(moe) gid=22(stooges) 14 $ echo "write test" >> file1 15 file1: cannot create 16 $ exit 17 sunsys> setfacl -m m:rw- file1 18 sunsys> getfacl file1 19 # file: file1 20 # owner: jim 21 # group: staff 22 user::rw- 23 user:moe:rw- #effective:rw- 24 group::r-- #effective:r-- 25 mask:rw- 26 other:r-- 27 sunsys> su moe 28 Password: 29 $ echo "write test" >> file1 30 $ exit 31 sunsys>In this example we displayed the ACL of file1 (lines 1 to 9) that show the mask is set for read only (8), but Moe has read/write permissions (6). After becoming user Moe (10-13), we attempt to write to file1 (14), and the write fails (15, with a rather non-descriptive error message).
We reset the ACL mask using setfacl(1) (line 17 -- and verified the change (18-26; note the mask set to read/write on line 25). Now we try the test again, again becoming user Moe (line 17 -- I had to revert to user Jim in order to change the ACL mask, since only the file owner can alter the ACL). This time, the test (29) is successful. Thus, we see that the ACL mask will supercede individual user permissions. Note that in the setfacl(1) command on line 17, we abbreviated the entry type mask using just the letter m. The command allows for this type of abbreviation, such that the letters u and g can be used in place of user and group, respectively.
We obviously haven't covered every possible permutation of ACL permission settings. The goal here was to provide enough introductory information to get the reader off to a comfortable start using ACLs. For more information on the specifics of using ACLs, consult the setfacl(1) and getfacl(1) man pages, as well as the Solaris documentation set. For working with file ACLs programmatically, there are system calls, acl(2) and facl(2), and library routines, aclcheck(3) and aclsort(3).
[Duke University] Using Solaris ACLs
If you need more complex file permissions than the standard UNIX permissions allow for, you may want to consider using Access Control Lists (ACLs) under Solaris. These allow you to set permissions on your files and directories to grant or deny access to arbitrary combinations of individual users and groups.
Note: The ACLs will only work under Solaris. So for networked filesystems, both the server and the client must be running Solaris.
We will consider a file created with typical UNIX permissions:
user@login% ls -l testfile -rw-r--r-- 1 user prof 2352 Jan 29 13:37 testfileThe default ACL for this file can be seen using the getfacl command:
user@login% getfacl testfile # file: testfile # owner: user # group: prof user::rw- group::r-- #effective:r-- mask:r-- other:r--The user and group permissions are those for the owner (user) and the default group (prof), respectively. The mask indicates the maximum permission available to all users, except the owner. The effective permission, to the right of the group permission, represents the intersection (bitwise AND) of the specified permissions for a user/group and the mask field. The effective permission is what a user, other than the owner, will see when they try to access the file.
For files with ACL entries, the chmod command will change the default mask for the file, as well as change the standard UNIX permissions. From the setfacl manual page:
``The ACL mask indicates the maximum permissions allowed for users (other than the owner) and for groups. The mask is a quick way to change permissions on all the users and groups.''To add ACL entries to a file, one uses the setfacl command. The syntax for an access record is
token:name:permsThere are several possible tokens; a short, but mostly comprehensive list of the possible types of ACL entries is as follows:
user:uid:perms group:gid:perms other:perms mask:permsHere uid/gid may be either a UNIX user/group name or a numeric user/group ID. The perms are standard UNIX file permissions (i.e. r,w,x). Permissions may be specified either as symbolic characters or a number (the same as for the chmod command). Multiple records may be added by a single command, separated by commas.
To add/modify records using the setfacl command, one of three options is required. The -s option will set the ACL, replacing any previous entries. The -m option will modify or add, an additional entry and the -f filename will set ACL entries as contained in filename. ACL entries can be removed from a file using the -d option can be used to remove one or more ACL entries. Additionally the -r option can be used to automatically recalculate the mask to give the proper access for a newly set/modified ACL; otherwise an ACL mask entry must be given on the command line. The default mask can also be changed using the standard UNIX chmod command.
For example, to add ``read'' and ``write'' permissions for the group tune, the following command would be used:
user@login% setfacl -r -m group:tune:rw- testfileThe -m option causes the default ACL to be modified, the -r option recalculates the ACL mask for the file. The output of the getfacl command might then read:
user@login% getfacl testfile # file: testfile # owner: user # group: prof user::rw- group::r-- #effective:r-- group:tune:rw- #effective:rw- mask:rw- other:r--Note the addition of the group entry for the tune group as well as the recalculated mask entry. The output of the ls command will now reflect that ACLs have been enabled for this file by the addition of a + at the end of the regular UNIX permissions.
user@login% ls -l testfile -rw-r--r--+ 1 user prof 2352 Jan 29 13:38 testfileMembers of the group tune may now read and write to this file. Note that using the chmod command on the file will change the default mask, possibly preventing users or groups from accessing the file. Be sure that the "effective" permissions shown in the ACL match the permission you wish to give to a user or group.
To turn the permissions for a file "off" use the -d option to setfacl, specifying which access record to delete:
user@login% setfacl -r -d group:tune testfileThe dtfile file manager provides an easy, graphical interface to managing Solaris ACLs. Under the Selected->Properties menu there is a button to "Show Access Control List". Here permissions for a particular user or group can be added to or removed from a file. The program makes sure the mask setting is correct to give the intended permissions. This program is part of the CDE desktop environment, but can be invoked under OpenWindows as well.
ACLs on directories
ACLs can also be set on directories. If regular ACLs are set as with the file example above, the effect is just to control access to the directory. An additional class of ACLs are also available for use on directories; these are called default ACLs. Default ACLs automatically propagate to any new files and directories created in this directory. This will also effect (set) the permission bits on the created files. This can be used as a mechanism to, eg, automatically set g+w on new files, which might be useful in certain shared directories.
Default ACLs are a bit complex and are out of the scope of this document. Please consult the setfacl manual page for more details.
[Oliver2001] Sys Admin Magazine Achieving More Flexible File Permissions Using Solaris ACLs by Ross Oliver
The fixed set of UNIX file permissions for owner, group, and world is simple to understand and easy to manage. However, the simplicity of this scheme is also its most frustrating limitation. Most UNIX systems administrators have at one time or another wished for just one more set of permissions to accomplish some necessary task.
Traditional workarounds include multiple user accounts, multiple group memberships, and set-UID programs. Although these methods work, they are not ideal because they add complexity, require root access to implement, and often raise security problems.
In the Solaris world, these limitations were finally overcome with the introduction of Access Control Lists (ACLs). Introduced in Solaris 2.5, ACLs are additional sets of read/write/execute triplets that can be added on to files, directories, devices, or any other file system objects. Using ACLs, systems administrators as well as ordinary users can now fine-tune access without resorting to multiple groups or set-UID programs. This article is a practical look at how to use ACLs on a real network.
[Grünbacher2003] POSIX Access Control Lists on Linux by Andreas Grünbacher
SuSE Linux 8.1 supports ACLs on the ext2 and ext3 file systems. ACL support is also present in xfs and jfs, but using ACLs with either xfs or jfs is not recommended at this point, because there are known issues on both file systems. ACL support on reiserfs is also forthcoming, but the necessary code is not activated in the kernel released with SuSE Linux 8.1. After all file systems have passed our internal ACL tests, we will release an updated kernel for SuSE Linux 8.1.
Activating ACLs
In the default settings after installation, ACLs are deactivated on ext2, ext3, and on reiserfs. They can be activated for supported systems using the "acl" mount option, which should be added at the appropriate place in /etc/fstab (see the SDB article Mounting, Partitioning, and Configuring File Systems (http://portal.suse.com//sdb/en/1996/02/maddin_fstab.html )). On the jfs and xfs file systems, ACLs are always enabled, so there is no "acl" mount option.
Manipulating ACLs
The basic permissions for the owner, owning group, and for others are also called minimal ACL. In addition to these three entries, an ACL may contain permissions for other users or groups. An ACL that has more than the three basic entries is called an extended ACL.
Files that have an extended ACL are recognized by the additional "+" character that is added to "ls -l" directory listings. The "getfacl" [getfacl(1)] command displays the complete permissions of a file. ACLs are modified with the "setfacl" [setfacl(1)] command. Additionally, "cp -p" copies ACLs between files.
Under Solaris, the ACL's have been put on top of the standard permissions. A directory has access control in effect if the permissions are followed by a "+".
# ls -ld tools -rwxr-xr-x+ 29 myers nogroup 8192 Feb 21 16:51 toolThe command getfacl will report on all access controls on a file:
algol -> getfacl tools # file: tool # owner: myers # group: nogroup user::rwx group::r-x #effective:r-x group:biostcs:rw- #effective:r-- mask:r-x other:r-xFor a full description of what all this means, refer to getfacl. The simple explanation is that most of it is standard Unix information in tabular form. Only the line
group:biostcs:rw- #effective:r--is a permission beyond those displayed in the
lsline above. It says that group "biostcs" can read and write the file.In order to make the "true" ACL's (i.e. ACL's that are extensions to standard permissions) more readable, the BCG supplies the command gacl:
# gacl tool group:biostcs:rw-The command setfacl is used to set a new ACL. We'll let
cjohnsonreadtool:# gacl tool group:biostcs:rw- # setfacl -m user:cjohnson:r-- tool # gacl tool user:cjohnson:r-- group:biostcs:rw-The
-moption means "modify".Later, we want to remove all ACL's. This could be done with
setfacl, but the syntax is somewhat painful, so we've supplied the command rmacl to remove all ACL's:# rmacl tool -rwxr-xr-x 29 myers nogroup 8192 Feb 21 16:51 toolThere are several other features to ACL's and many ways to manipulate them. Refer to setfacl and getfacl for the gruesome details.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019
