|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
Solaris Advanced System Administrator's Guide, Second
(Imprint: Macmillan Technical Publishing)
(Publisher: Macmillan Computer Publishing)
Author: Janice Winsor
Access Control Lists (ACLs, pronounced ackkls) can provide greater control over file permissions when traditional UNIX file permissions are not enough. UNIX file protection provides read, write, and execute permissions for three user classes: owner, group, and other. An ACL provides better file security by enabling you to define file permissions for the owner, owner's group, others, specific users, and groups. It also enables you to define default permissions for each of these categories.
For example, you might have two groups that need permission to access a file, one to read it and one to write to it. Alternatively, you might have a file that you wanted everyone in a group to be able to read, so you would give group read permissions on that file. Suppose that you want only two people in the group to be able to write to that file. With standard UNIX permissions, you cannot give write permission to only two members of a group. You can, however, set up an ACL for that file to grant only two people in the group write permissions on that file.
ACLs are extensions to standard UNIX file permissions. The ACL information is stored and associated with each file individually.
You define an ACL for a file or directory by using the ACL commands and options listed in Table 18-8.
|getfacl||Displays ACL entries.|
|-a||Displays the filename, owner, group, and ACL of the file.|
|-d||Displays the filename, owner, and group of the file. The information is displayed even if the file does not have an ACL.|
|setfacl||Sets, adds, modifies, and deletes ACL entries.|
|-s acl_entries||Sets the ACL for the file, removing all old entries and replacing them with the newly specified ACL.|
|-m acl_entries||Adds one or more new ACL entries to the file or modifies one or more existing ACL entries for the file. If an entry already exists, the specified permissions replace the current permissions. If no entry exists, a new entry is created.|
|-d acl_entries||Deletes one or more entries from the file. You cannot delete entries for the file owner, the owning group, and other. Note that deleting an entry does not necessarily have the same result as removing all permissions from the entry.|
|-f acl_file||Specifies a file containing the ACL entries to be used as arguments to the setfacl command.|
|-r||Recalculates permissions for the ACL mask. Permissions specified in the mask are ignored and replaced by the maximum permissions needed to give access to any additional user, owning group, and additional group entries in the ACL.|
Each ACL entry consists of the following fields, which are separated by colons:
<entry-type>:[<UID>] | [<GID>]:<perms>
Table 18-9 explains each of the elements of the syntax for ACL commands.
|<entry-type>||Type of ACL entry on which to set file permissions. For example, <entry_type> can be user (the owner of a file) or mask (the ACL mask).|
|<UID>||Username or identification number.|
|<GID>||Group name or identification number.|
|<perm>||Permissions set for the <entry-type>. Permissions can be set symbolically using the characters r, w, x, and - or by using octal values from 0 to 7.|
NOTE: ACLs are supported in UFS file systems only. If you restore or copy files with ACL entries in the /tmp directory, which is usually mounted as a TMPFS file system, the ACL entries are lost. If you need to temporarily store UFS files containing ACLs, use the /var/tmp directory instead.
You can set the following permissions for UFS files:
You can set default ACL entries on a directory that apply to files subsequently created within the directories. Files created in a directory that has default ACL entries will have the same ACL entries as the directory.
When you set default ACL entries for specific users and groups on a directory for the first time, you must also set default ACL entries for the owner, owner's group, others, and the mask.
You can determine if a file has an ACL in one of two ways:
When you use the ls -l command, any file that has an ACL displays a plus (+) sign to the right of the mode field.
NOTE: If you define an ACL for a file and do not specify any additional users or groups, the plus sign is not displayed to the right of the mode field even though the file has a basic ACL. The plus sign is displayed only if additional users or groups are included in the ACL.
In the following example, the file foo has an ACL and at least one entry in the list:
castle% ls -l foo -rwxrw+ 1 winsor staff 0 Oct 3 14:22 foo castle
When you use the getfacl <filename> command with no options, the ACL information for the file is displayed in the following format:
# file: filename # owner: uid # group: gid user::perm user:uid:perm group::perm group:gid:perm mask:perm other:perm default:user::perm default:user:uid:perm default:group::perm default:group:gid:perm
The ACL for the file foo in the following example gives the owner of the file rwx permissions and user ray read-only permissions:
castle% getfacl foo # file: foo # owner: winsor # group: staff user::rwx user:ray:r-- #effective:r-- group::rw- #effective:rw- mask:rw- other:--- castle%
NOTE: You can use the getfacl command to display permissions on any UFS file or directory in the same format. The file does not need to have an ACL.
For comparison, the following example shows the output of the ls -l and getfacl commands for the file bar, which does not have an ACL.
castle% ls -l bar -rwxrw 1 winsor staff 0 Oct 3 14:22 bar castle% getfacl bar # file: bar # owner: winsor # group: staff user::rwx group::rw- #effective:rw- mask:rw- other: castle%
Use the setfacl command to set ACL permissions on a file. You can set the permissions for a file or a group of files from a command line or by listing the permissions in a file and using the file as an argument to the setfacl command. You can specify the permissions with the following syntax:
u[ser]::<perm> u[ser]:uid:<perm> g[roup]::<perm> g[roup]:gid:<perm> m[ask]:<perm> o[ther]:<perm> d[efault]:u[ser]::<perm> d[efault]:u[ser]:uid:<perm> d[efault]:g[roup]::<perm> d[efault]:g[roup]:gid:<perm> d[efault]:m[ask]:<perm> d[efault]:o[ther]:<perm>
NOTE: You can use either octal or symbolic values to set permissions.
On a command line, use a comma to separate each permission statement. In an ACL file, put each statement on a separate line. The statements do not need to be in any particular order
To set ACL permissions from a command line, you must specify at least the basic set of user, group, other, and mask permissions. Type the following command to set ACL permissions: setfacl -s u::<perm>,g::<perm>,o:<perm>, m:<perm>, [u:<UID>:<perm>], [g:<GID>:<perm>
You can set users by using either their username or their UID number. Note that before you can use the username argument, the user account must already exist in the Passwd database or in the local /etc/passwd file. You can assign permissions to any UID by number, regardless of whether a user account exists.
In the same way, you can set group names by using either the group name or the GID number.
The following example assigns all of the permissions to the user, restricts group permissions to read-only, and denies permissions to other. The default mask sets read-write permissions, and user ray is assigned read-write permissions to the file foo.
First, take a look at the current permissions for the file:
castle% ls -l foo -rw-rw-rw- 1 winsor staff 0 Oct 3 14:22 foo
Then set permissions for user, group, owner, and the mask and add one user to the ACL:
castle% setfacl -s u::rwx,g::r,o:,mask:rw-,u:ray:rw- foo
Using octal values, as shown in the following example, gives you the same result:
castle% setfacl -s u::7,g::4,o:0,mask:6,u:ray:6 foo
Next, verify that the permissions have been set and that the file has an ACL:
castle% ls -l foo -rwxrw + 1 winsor staff 0 Oct 3 14:22 foo
As you can see, the permissions for the file are changed and the plus sign after the permission field shows that the file has an ACL. Last, use the getfacl command to verify that everything has been set correctly:
castle% getfacl foo # file: foo # owner: winsor # group: staff user::rwx user:ray:rw- #effective:rw- group::rw- #effective:rw- mask:rw- other: castle%
The getfacl command always displays ACL permissions symbolically, regardless of how you specify the values from the command line.
You can create an ACL configuration file that contains a list of the permissions you want to set and then use that filename as an argument to the setfacl -s command.
NOTE: You can use a configuration file only with the -s option to the setfacl command.
Use the following steps to set up the ACL configuration file:
NOTE: If you make typographical errors in the configuration file, the command might return a prompt without displaying any error messages. If you make syntax errors, the setfacl command might display an error message. Be sure to use the getfacl command to check that the permissions are set properly.
In the following example, the owner has rwx permissions, group has rw-, other has , and the mask is rw-. Three users with different permissions are also granted access to the file. The acl_file (named anything) contains the following access list:
u::rwx g::rw- o: m:rw- u:ray:rwx u:des:rw- u:rob:r
Once you have set up the ACL for the file named anything, you can use the setfacl -f option to assign those same permissions to one more file. In the following example, the file named anything is used as the argument to the -f option to change ACLs for the files foo and bar so that they match the file anything:
castle% setfacl -f anything foo bar castle% getfacl foo bar # file: foo # owner: winsor # group: staff user::rwx user:ray:rwx #effective:rwx user:des:rw- #effective:rw- user:rob:r #effective:r group::rw- #effective:rw- mask:rw- other: # file: bar # owner: winsor # group: staff user::rwx user:ray:rwx #effective:rwx user:des:rw- #effective:rw- user:rob:r #effective:r group::rw- #effective:rw- mask:rw- other: castle%
You can add and modify ACL permissions for a file that already has an ACL or for any existing UFS file or directory by using the setfacl -m command. Arguments to the setfacl -m command use the same syntax and structure as arguments to the setfacl -s command.
Because each file already has a default owner, group, other, and mask setting, you can use the setfacl -m command on any UFS file without first using the setfacl -s command to specify an owner, group, other, or mask setting. If the file already has the permissions you want to use, you can simply use the setfacl -m command to modify (and create) the ACL for any file or directory.
When you use the -m option, if an entry already exists for a specified UID or GID, the permissions you specify replace the current permissions. If an entry does not exist, it is created.
Type the following syntax to add and modify permissions for a file or files and press Return:
setfacl -m <acl_entry_list><filename1> [<filename2>] [<filename3>]
In the following example, permissions for user ray are modified from rwx to rw- for the file foo.
castle% setfacl -m u:ray:rw- foo castle% getfacl foo # file: foo # owner: winsor # group: staff user::rw- user:ray:rw- #effective:rw- group::rw- #effective:rw- mask:rw- other:rw- castle%
Use the setfacl -d command to delete an ACL entry. To delete the entry, you can specify the entry type and the UID or GID. You do not need to include the permissions as part of the argument to the -d option.
Type the following syntax to delete an ACL entry and then press Return:
setfacl -d<entry_type>:<UID> | <GID> <filename1> [<filename2>] [<filename3>]
In the following example, user ray is deleted from the ACL of the file foo.
castle% setfacl -d u:ray foo castle% getfacl usage: getfacl [-ad] file ... castle% getfacl foo # file: foo # owner: winsor # group: staff user::rw- group::rw- #effective:rw- mask:rw- other:rw- castle%
You can copy ACL file permissions from one file to another without specifying them on the command line by piping the output of getfacl <filename> to another file by typing the following syntax and pressing Return:
getfacl <filename1> | setfacl -f - <filename2>
In the following example, the ACL for file foo is used as the template for the ACL for file bar.
First, verify that the files have different ACL permissions:
castle% getfacl foo bar # file: foo # owner: winsor # group: staff user::rw- user:ray:rwx #effective:rw- group::rw- #effective:rw- mask:rw- other:rw- # file: bar # owner: winsor # group: staff user::rw- group::rw- #effective:rw- mask:rw- other:rw-
Then list the ACL using the getfacl command and pipe the output to the setfacl -f command. The dash (-) tells the setfacl command to use the output from the file specified for the getfacl command as input to the second file.
castle% getfacl foo | setfacl -f - bar
Finally, use the getfacl command to verify that both files now have the same ACL permissions:
castle% getfacl foo bar # file: foo # owner: winsor # group: staff user::rw- user:ray:rwx #effective:rw- group::rw- #effective:rw- mask:rw- other:rw- # file: bar # owner: winsor # group: staff user::rw- user:ray:rwx #effective:rw- group::rw- #effective:rw- mask:rw- other:rw- castle%
Networks create an interesting access and security paradox. Users on a network almost always push for freer access to information and files. System administrators almost always push for more restrictive access to information and files so that they can more effectively monitor use and secure access to sensitive information.
Network security is usually based on limiting or blocking operations from remote systems.
Network security comprises three aspects: firewall, authentication, and authorization, as illustrated in Figure 18-1.
Figure 18-1 Security Restrictions for remote operations.
The purpose of creating a firewall network security system is to ensure that all of the communication between a local network and an external network conforms to your local network security policy. A network security policy can be permissive or restrictive. A permissive policy might allow access to all services unless specifically denied. A restrictive policy might deny access to all services unless specifically allowed.
You can set up a firewall system to help protect the resources in your network from outside access. A firewall system acts as a barrier between your internal network and outside networks.
The firewall has two functions:
CAUTION! A firewall prevents unauthorized users from accessing hosts on your network. Maintain strict and rigidly enforced security on the firewall. However, an intruder who can break into your firewall system may be able to gain access to all of the other hosts on the internal network.
A firewall system should not have any trusted hosts. A trusted host is one from which a user can log in without being required to type in a password. The firewall system should not share any of its file systems or mount any file systems from other servers.
You can use ASET to make a system into a firewall and to enforce high security on a firewall system. For more information on ASET, refer to Chapter 20.
Two good reference books on firewalls are Firewalls & Internet Security: Repelling the Wily Hacker by Steven Cheswick and William Bellovin and Building Internet Firewalls by D. Brent Chapman and Elizabeth D. Zwicky. (See bibliography at the end of this book.)
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
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
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
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
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 Haters 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-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and 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 make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: September 12, 2017