www.delorie.com/gnu/docs/cfengine/cfengine-Tutorial_60.html   search  
 
Buy GNU books!


GNU cfengine

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.12 Managing ACLs

Access control lists are extended file permissions. They allow you to open or close a file to a named list of users (without having to create a special group for those users). They also allow you to open or close a file for a named list of groups. Several Unix-like operating systems have had access control lists for some time; but they do not seem to have caught on.

There is a number of reasons for this dawdling in the past. The tools for setting ACLs are generally interactive and awkward to use. Because a named list of users would lead to excessive verbosity in an ls -l listing, one does not normally see them. There is therefore the danger that the hidden information would lead to undetected blunders in opening files to the wrong users. ACLs are also different on every vendor's filesystems and they don't work over intersystem NFS. In spite of these reservations, ACLs are a great idea. Here at Oslo College, it seems that users are continually asking how they can open a file just for the one or two persons they wish to collaborate with. They have grown used to Novell/PC networks which embraced the technology from Apollo/NCS much earlier. Previously the Unix answer to users has always been: go ask the system administrator to make a special group for you. Then do the `chmod' thing. And then they would say: so what's so great about this Unix then?

Addressing this lack of standardization has been the job of a POSIX draft committee. Some vendors have made their implementations in the image of this draft. Solaris 2.6 has a good implementation. In spite of this, even these systems have only awkard tools for manipulating ACLs. Not the kind of thing you want to be around much, if you have better things to do. But the incompatibility argument applies only to multiple vendor headbutting. Some institutions who share data on a global basis opt for advanced solutions to network filesystems, such as AFS and DFS. Filesystems such as DCE's DFS make extensive use of file ACLs, and they are not operating system specific. Even so, DFS provides only interactive tools for examining and setting file permissions, and this is of little use to system administrators who would rather relegate that sort of thing to a script.

The need for this kind of thing is clear. Systems which make use of ACLs for security can be brought to their knees by changing a few ACLs. Take the Apollo/Domain OS as an example. All one needs to do to kill the system is to change a few ACLs and forget what they were supposed to be. Suddenly the system is crippled, nothing works. The only solution, if you don't have a backup, is to remove all of the security. Unix has a simpler security philosophy when it comes to the operating system files, but ACLs would be a valuable addition to the security of our data.

A cfagent bare-bones file-checking program looks like this:

 
#
# Free format cfagent program
#

 control:

   ActionSequence - ( files )

 files:

   classes::

     /directory/file  mode=644 
                      owner=mark,ds
                      group=users,adm
                      acl=zap 
                      action=fixplain

  # ... more below

This program simply checks the permissions and ownership of the named file. The regular file mode, owner and group are specified straightforwardly. The new feature here is the acl directive. It is a deceptively simply looking animal, but it hides a wealth of complexity. The zap is, of course, not an access control list. Rather, cfagent uses a system of aliases to refer to ACLs, so that the clutter of the complex ACL definitions does not impair the clarity of a file command. An ACL alias is defined in a separate part of the program which looks like this:

 
 # ...contd


 acl:

   { zap

   method:append
   fstype:solaris
   user:rmz:rwx
   user:len:r
   }

As you can see, an ACL is a compound object--a bundle of information which specifies which users have which permissions. Because ACLs are lists the alias objects must also know whether the items are to be appended to an existing list or whether they are to replace an existing list. Also, since the permission bits, general options and programming interfaces are all different for each type of filesystem, we have to tell cfagent what the filesystem type is.

It is possible to associate several ACL aliases with a file. When cfagent checks a files with ACLs, it reads the existing ACL and compares it to the new one. Files are only modified if they do not conform to the specification in the cfengine program. Let's look at a complete example:

 
 files:

   $(HOME)/myfile acl=acl_alias1 action=fixall

 acl:

   { acl_alias1

   method:append
   fstype:solaris
   user:len:rwx
   }

ACLs are viewed in Solaris with the command `getfacl'. Suppose that, before running this program, our test-file had permissions

 
   user:*:rwx
   user:mark:rwx           #effective:r-x
   group:*:r-x              #effective:r-x
   mask:r-x
   other:r-x
   default_user:rw-
   default_group:r--
   default_mask:-w-
   default_other:rwx

After the cfagent run, the ACL would become:

 
   user:*:rwx
   user:mark:rwx           #effective:r-x
   user:len:rwx            #effective:r-x
   group:*:r-x              #effective:r-x
   mask:r-x
   other:r-x
   default_user:rw-
   default_group:r--
   default_mask:-w-
   default_other:rwx

Suppose we wanted to to remove 'w' bit for user `jacobs', or make sure that it was never there.

 
	{ acl_alias1

	method:append
	fstype:solaris
	user:jacobs:-w
	}

Note that the method used here is append. That means that, whatever other access permissions we might have granted on this file, the user `jacobs' (a known cracker) will have no write permissions on the file. Had we used the method overwrite above, we would have eliminated all other access permissions for every user and added the above. If we really wanted to burn `jacobs', we could remove all rights to the file like this

 
  user:jacobs:noaccess

The keyword noaccess removes all bits. Note that this is not necessarily the same as doing a -rwx, since some filesystems, like DFS, have more bits than this. Then, if we want to forgive and forget, the ACLs may be removed for jacobs with the syntax

 
  user:jacobs:default

In Solaris, files inherit default ACLs from the directory they lie in; these are modified by the umask setting to generate their own default mask.

DFS ACLs look a little different. They are examined with the `acl_edit' command or with

 
dcecp -c acl show <filename>

In order to effect changes to the DFS, you have to perform a DCE login to obtain authentication cookies. The user `cell_admin' is a special user account for administrating a local DFS cell. Suppose we have a file with the following DCE ACL:

 
  mask_obj:r-x---
  user_obj:rwxcid
  user:cell_admin:r--c-- #effective:r-----
  group_obj:r-x--d       #effective:r-x---
  other_obj:r-x---

Now we want to add `wx' permissions for user `cell_admin', and add new entries with `rx' permissons for group acct-admin and user `root'. This is done with the following ACL alias:

 
   { acl_alias2

   method:append
   fstype:dfs
   user:/.../iu.hioslo.no/cell_admin:wx
   group:/.../iu.hioslo.no/acct-admin:rx
   user:/.../iu.hioslo.no/root:rx
   user:*:-x
   }

The local cell name `/.../iu.hioslo.no' is required here. Cfagent can not presently change ACLs in other cells remotely, but if your cfengine program covers all of the cell servers, then this is no limitation, since you can still centralize all your ACLs in one place. It is just that the execution and checking takes place at distributed locations. This is the beauty of cfengine. After running cfagent, with the above program snippet, the ACL then becomes:

 
  mask_obj:r-x---
  user_obj:rwcid
  user:cell_admin:rwxc-- #effective:r-x---
  user:root:r-x---       #effective:r-x---
  group_obj:r-x--d       #effective:r-x---
  group:acct-admin:r-x---
  other_bj:r-x---

For the sake of simplicity we have only used standard Unix bits `rwx' here, but more complicated examples may be found in DFS. For example,

 
 user:mark:+rwx,-cid

which sets the read, write, execute flags, but removes the control, insert and delete flags. In the DFS, files inherit the inital object ACL of their parent directory, while new directories inherit the initial container object.

The objects referred to in DFS as user_obj, group_obj and so forth refer to the owner of a file. i.e. they are equivalent to the same commands acting on the user who owns the file concerned. To make the cfengine user-interface less cryptic and more in tune with the POSIX form, we have dropped the `_obj' suffices. A user field of `*' is a simple abbreviation for the owner of the file.

A problem with any system of lists is that one can generate a sequence which does one thing, and then undoes it and redoes something else, all in the same contradictory list. To avoid this kind of accidental interaction, cfengine insists that each user has only one ACE (access control entry), i.e. that all the permissions for a given user be in one entry.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

  webmaster   donations   bookstore     delorie software   privacy  
  Copyright 2003   by The Free Software Foundation     Updated Jun 2003