One of the major criticisms of Linux (and other *nix-like operating systems) is that the security model used to limit access to file system objects is, well, a little long in the tooth. While I think that the model has held up pretty well, I do admit that the gyrations that it puts me through can be irritating.
For those unfamiliar, the security model is quite simple (which is both its beauty and its weakness). Access to a file system object can be controlled within three categories of users: the owner of the object, the group that owns the object, and anyone who is an authorized user of the system, sometimes called "world privileges." Any of those three categories can be given authority to read, write, and execute (manage) objects. This should be familiar to anyone who has used the Qshell or qp2term interface on the i5 to manipulate objects that reside in the IFS. While this security model has worked quite well for the decades that Unix has been in existence, its a real pain in the butt for an administrator. Creating the means for users to easily share files can be particularly cumbersome and time-consuming, generally requiring an administrator to cluster users into groups and then make sure that the permissions on the directories or objects are suitably set.
Manipulating IFS object permissions from the i5/OS side not only is much simpler than from Qshell, but also yields much more flexible and finer-grained security. From the WRKAUT command (or if you're a GUI type, the OpsNav interface), you can grant or prohibit access using the same owner/group and world basis, as in the Qshell interface, but you can go much deeper and assign access privileges to objects down to a per-user basis. What many Linux users may not know is that Linux has similar capabilities, called access control lists (ACLs). This month, we'll look at Linux ACLs and learn how to put them to use at your installation.
Turning On
While most Linux distributions support ACLs, most do not have them enabled by default. Fortunately, the effort you need to put forth to activate ACLs is minimal. First, you need to ensure that your distribution has ACL support. Perhaps the easiest way to accomplish this is to issue the command getfacl. from a command line. If you get a response that looks something like this, it's likely that you have ACL support:
# file: .
# owner: klinebl
# group: klinebl
user::rwx
group::---
other::---
Why do I say "likely"? It's because I doubt that any distribution that doesn't support ACLs would have one of the programs used for manipulating them. There are more distribution-specific means to check for ACL support, but I'll leave you to the documentation for that.
Having determined that your system supports ACLs, you then need to ensure that you have a properly partitioned system. By that I mean one that has the directory (or directories) for which you want ACL support separated from the system root directory. If you issue the command mount and see something like this, you may want to reconsider experimenting with ACLs.:
/dev/mapper/vg0-sysroot on / type ext3 (rw,noatime)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbfs on /proc/bus/usb type usbfs (rw)
none on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/hdc on /media/cdrecorder type iso9660 (ro,nosuid,nodev,user=klinebl)
(Note that the only partition listed actually containing disk space is the system root, '/').
It's not that you can't use ACLs on a system configured with one large partition. It's just that the potential to misconfigure your permissions such that you expose yourself to security or operational issues is just too great.
What you want to see is something like this:
/dev/mapper/vg0-sysroot on / type ext3 (rw)
/dev/mapper/vg0-home on /home type ext3 (rw)
Here, I edited out the superfluous entries shown earlier to make the list shorter. Note that I now have two partitions, one containing the system root and one hosting the '/home' directory, the typical partition for storing users' data.
Turning on ACLs is truly a simple task. You may do so in one of two ways. The first is to edit the file '/etc/fstab' and indicate that you want ACL support. In my case, that means changing this line
to this:
The next time you start your system, ACL support will be enabled. To enable it immediately, simply issue the command mount -o remount /home. If you want to enable ACL support without editing the file (requiring you to manually enable support after every system restart), then issue the command mount -o remount,acl /home.
Once you have restarted or remounted the file system, you should be able to issue the mount command with no parameters and see something similar to this:
/dev/mapper/vg0-sysroot on / type ext3 (rw)
/dev/mapper/vg0-home on /home type ext3 (rw,acl) <--- NOTICE acl
If you do, you're ready to start assigning permissions.
ACL User-Space Tools
To make this discussion easier, consider the following scenario: Your two co-workers, Dick and Jane, are going to collaborate with you on a project. It is imperative that you have a single directory that is accessible by all three of you. Normally, you'd need to contact the system administrator for her assistance in setting this up. Traditionally, she'd create a new group and make you all members. Then, she'd set up a directory and set the directory's owner to the new group, followed by turning on the "sticky" bit (which makes the directory's owner the owner for all objects created within it). That way, any of the three of you would be able to access any file in the directory, regardless of who created it.
The problem with this scenario is that the system administrator must become involved, which may or may not be a stumbling block for you. Using ACL tools, you are able to take care of this issue yourself without the sysadmin either caring or knowing what you are doing. Since you're the project lead, you decide to create a subdirectory of your home directory, which you call "trinity." Here are the commands you issued:
[you@laptop2 ~]$ ls -ld trinity
drwxrwxr-x 2 you you 4096 Apr 20 13:28 trinity
As you can see, "you' is the user who owns the object (third column) and the "you' group has read,write,and execute permissions (fourth column) on this newly created directory. (Traditional Unix has a group called "users" to which all system users are assigned. Red Hat, among others, takes a different tack; they create a group per-user name. The reason is for enhanced security, since it's less likely that you'll inadvertently open up private objects to every user on your system!)
The two basic commands for managing ACLs are setfacl and getfacl. As you can guess, the former is to set them and the latter is to retrieve them. Let's see what getfacl says about our new directory:
# file: trinity
# owner: you
# group: you
user::rwx
group::rwx
other::r-x
You'll note that it's the same information as from the ls command, just in a more verbose format.
Having created the directory, you'll now add ACL information to allow your cohorts to access the files. While you're at it, you set the default ACL, which files created within the "trinity" directory will inherit:
[you@laptop2 ~]$ setfacl -m u:jane:rwx,g::-,o::- trinity
[you@laptop2 ~]$ setfacl -d -m u::rwx,g::rwx,o::rwx trinity
[you@laptop2 ~]$ ls -l
total 8
drwxrwx---+ 2 you you 4096 Apr 20 14:31 trinity
[you@laptop2 ~]$ getfacl trinity
# file: trinity
# owner: you
# group: you
user::rwx
user:dick:rwx
user:jane:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:other::rwx
Notice the plus sign in the output of the ls command; this indicates that there are ACLs applied to the directory. The getfacl command shows that you have the desired settings. You give Dick a call on the phone and ask him to create a file in that directory. He sees this:
touch: cannot touch `/home/you/trinity/testfile': Permission denied
What's wrong? While Dick has permission to the trinity directory, he doesn't have it to your home directory (/home/you), thus he can't look at anything below your home directory. You fix that for him and Jane by typing this:
[you@laptop2 ~]$ getfacl /home/you
getfacl: Removing leading '/' from absolute path names
# file: home/you
# owner: you
# group: you
user::rwx
user:dick:--x
user:jane:--x
group::---
mask::--x
other::---
Why give only execute "x" permissions on the home directory? You want Dick and Jane to be able to work with the files in the trinity directory, but you'd rather keep the other things in your home directory private. Dick retries creating a file in the trinity directory, and this time he succeeds. He isn't able to see your home directory, though:
[dick@laptop2 ~]$ ls -l /home/you/trinity
-rw-rw-rw- 1 dick dick 0 Apr 20 14:31 testfile
[dick@laptop2 ~]$ ls -l /home/you
ls: /home/you: Permission denied
As a final test, you check the permissions on the file that he created and attempt to alter it:
total 0
-rw-rw-rw- 1 dick dick 0 Apr 20 14:31 testfile
[you@laptop2 trinity]$ echo "Hello" >> testfile
[you@laptop2 trinity]$ cat testfile
Hello
[you@laptop2 trinity]$
You were successfully able to modify and read the file, in spite of the fact that user "dick" and group "dick" own the file. You IM Jane and ask her to give it a try:
[jane@laptop2 ~]$ cat /home/you/trinity/testfile
Hello
there
[jane@laptop2 ~]$
She has the proper access, as well. All three of you can now start working concurrently on the project. And you set it up without the help of the system administrator. Sweet!
Some Caveats
Posix ACLs are certainly a major improvement in managing Linux permissions. There are some things to keep in mind, however,
ACLs are not universally supported by most of the GNU utilities that come with Linux. Commands such as mv (for moving or renaming files) will duplicate the source ACL. The copy command (cp) will too, provided that you remember to use the '-p' switch. Obviously, the target partition of one of these commands must support ACLs for them to carry over.
Perhaps the most critical application that does not support ACLs is "tar," which many installations use for backup. If you save objects secured with ACLs using the standard tar utility and then try to restore them, you'll find that your carefully crafted access control list will be missing. There are workarounds for the backup situation. Instead of the standard tar utility, use its upgraded equivalent: star. This utility works similarly to tar, but it also understands ACLs. The only problem with star is that the command line switches are different, so it may break your existing backup scripts. An alternative, and the one that I use, is to simply use the getfacl command to write the existing ACLs to a file (say ACL.list) prior to a backup. Then if I need to restore files, I can use the setfacl command along with ACL.list to restore the ACLs.
Available Now
My intent in this article was to introduce you to ACLs. While Linux has supported ACLs for quite some time, it seems that many users are totally unaware of this fact.
Properly applied, ACLs can simplify even the most complex permissions requirement. So whether you are setting up a Web server, a Samba smb server (for sharing Linux resources with Windows clients), or a system for your users to work directly on the Linux machine, you owe it to yourself to learn more. There are plenty of good Web resources that will provide much more in-depth information than I can here in this limited space. I just wanted you to be aware that ACLs support is available now. Check it out!
Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 23 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online