Among airline industry mechanics, theres a hierarchy which puts those who service aircraft waste tanks at the bottom of the pole. Its the same in the IT industry except the lowest of the low handle desktop support. Vying for "lowest rung" status in the enterprise is "user management": the night staff who turn the Personnel Departments lists of staff changes into Active Directory entries.
They slot new staff entries into predefined groups that define the limits of new users rights. Predefined policies follow new users around the network, enforcing those limits across distributed network resources.
If only distributed user rights were so easily constrained on Linux.
Examine 10 Linux business servers and youll find eight still enforcing rights based on user membership of groups in the /etc/group file, one using NIS to do the same thing over a network and one using a half-built, not-fully-understood OpenLDAP deployment.
That may change as knowledge of Access Control Lists (ACLs) on Linux spreads. ACLs bring much finer-grained control over access to files, directories and devices that extend the standard nine-way Linux access control. Nine-way?
Imagine it this way: any file on a standard Linux system recognises three classes of user that might want to access it. They are the files owner, a group that also owns it and "other" where "other" is everybody and everything that wasnt in the first two categories.
For each of those three classes of user, each file, directory or device also recognises three types of access: read, write and execute. Three types of user with three types of access gives us a measly nine ways in which Linux might need to allow or deny access to a file, directory or device.
Contrast that with the confusing albeit powerful range of access control options coiled behind the "security" tab on each file in a Windows system.
What ACLs bring is the ability to more finely control which users can access a Linux file. Instead of being forced to limit, say, read access to "owner", "group", or "other", ACLs allow administrators to give read access to any combination of users, groups, and of course the owner.
That allows Administrators to delegate read or write access to important system files without giving away "root" access to the entire system. Simply use ACLs to delegate the necessary rights to a particular group, and then ensure that the appropriate users are also members of that group.
ACLs ability to interrogate centralised authentication systems like LDAP, NIS, and PAM mean group membership can be controlled across a network. Its all beginning to sound like Windows-style directory services are possible on a Linux network. And it thats possible, then Linux might have a smoother journey into the enterprise.
But a multitude of problems conspire to hold ACLs back.
The first is kernel recompilation. ACLs are available in source and RPM-style binary packages. Whichever installation method administrators use, they will also have to recompile the kernel. Most enterprises using mainstream distributions such as Red Hats do not recompile kernels so lightly. Most wait for the distributor to produced a kernel that has been back-tested and is backed by guarantee.
Application incompatibility is a second reason to stay clear of ACLs. Common system utilities currently offer widely varying support for the principle of ACLs, let alone for the practical application of them. No doubt that will change quickly. When it does, the new utilities will have to be installed on production systems. Expect delay. The more complex the application, the longer the likely delay.
The third is user unfamiliarity. This latter reason is particularly corrosive because so much Linux expertise is home-grown: its come out what Microsoft competitive analysts used to dismiss as "tinkerers". While ACL implementation planning, support and training may be available to big enterprises that are able to pay for it, most ACL support will have to come from consultants selling and supporting Linux into medium-sized businesses. Many of them are not willing to pay for, say, Novell or Red Hat to provide ACL training or ACL how-tos. Instead they will have to "tinker" on their test networks which do not provide a very realistic scenario for enterprise rights and permissions issues.
But the single most insuperable problem - today at least - is the fourth: the lack of decent management interfaces to integrate ACLs into operating system management.
To understand how critical this is, consider Windows Servers Group Policy Objects (GPOs). GPOs deploy easily identifiable sets of rights and permissions to easily identifiable and easily grouped users and resources across a network.
In a Linux version of a similar tool, ACLs merely allow resources such as files, directories and devices, to differentiate between more than three different user types ("owner", "group" and "other"). But ACLs do not present that larger range of users in an easy-to-use or visual tool that also manages user authentication. Nor does having ACLs available on a system create an easy way to assign rights to users en masse and to distribute them across distributed resources in an enterprise network.
For that, we will have to wait to see what mainstream distributors come up with. But you can bet that Linux vendors that are building relationships with enterprise IT buyers are busy drawing up specifications for those tools.
How ACLs work
A common problem scenario with traditional rwx access controls is their lack of granularity over which users are allowed to access a file object. Traditional rwx controls categorise users as "owner", "group, or "other". Administrators who wanted to give read access on a file to a specific non-owner user had to make that user a member of a group with read access to the file. Or give them superusers rights.
Either choice came with big implications
If the file sat in a directory whose mask forced non-read rights on the group, the group membership approach would not work. If the file already belonged to another group with read access, administrators might not be able to change the files group ownership without breaking a process. The classic examples of this are the user files in the mail spool directory in Unix systems, each of which has to be readable to the "mail" group used by the mail program. Change the group on the file belonging to user "dick" to group "specials" so that user "bob" a member of "specials" can read dicks mail and the mail program will no longer be able to access dicks mail.
Other distributions present interesting new problems of their own: Red Hat and Fedora both increase privacy by creating user-owned files in a group named after the user, of which the user is the only member. Make another user a member of this group called a User Private Group and you give that user read access to all the users files. This rather undermines the meaning of "Private".
ACLs solve that by allowing you to over-ride OS defaults on a per-user or per-group basis.