getfacl, setfacl

March 5, 2008 Leave a comment

From http://www.suse.de/~agruen/acl/linux-acls/online/

Traditionally, systems that support the POSIX (Portable Operating System Interface) family of standards [11,2] share a simple yet powerful file system permission model: Every file system object is associated with three sets of permissions that define access for the owner, the owning group, and for others. Each set may contain Read (r), Write (w), and Execute (x) permissions. This scheme is implemented using only nine bits for each object. In addition to these nine bits, the Set User Id, Set Group Id, and Sticky bits are used for a number of special cases. Many introductory and advanced texts on the UNIX operating system describe this model [19].

But there are obviously times this is insufficient.  Like, say Bob is working in a group with Alice, so he wants to share files with her, but they don’t want to share files with everybody else.  I guess root could go and create a group, add Bob and Alice to it, then they could set the file to the new group or whatever, but this becomes unmanagable with very large systems.

A short definition from the man page of what an ACL is

This manual page describes POSIX Access Control Lists, which are used to define more fine-grained discretionary access rights for files and directories.”

The following tags are defined

ACL_USER_OBJ The ACL_USER_OBJ entry denotes access rights for the file owner.
ACL_USER ACL_USER entries denote access rights for users identified by the entry’s qualifier.ACL_GROUP_OBJ The
ACL_GROUP_OBJ entry denotes access rights for the file group.
ACL_GROUP ACL_GROUP entries denote access rights for groups identified by the entry’s qualifier.
ACL_MASK The ACL_MASK entry denotes the maximum access rights that can be granted by entries of type ACL_USER, ACL_GROUP_OBJ, or ACL_GROUP.
ACL_OTHER The ACL_OTHER entry denotes access rights for processes that do not match any other entry in the ACL.

When an access check is performed, the ACL_USER_OBJ and ACL_USER entries are tested against the effective user ID. The effective group ID, as well as all supplementary group IDs are tested against the ACL_GROUP_OBJ and ACL_GROUP entries.

I won’t go into the not-really-that-gory details of how to implement it here, other than to say ACLs can be easily modified with the getfacl and setfacl commands.

So for example, if Alice wanted to give Bob read access to a file, she could type

$ setfacl -m u:Bob:r myfile

Filed under Pentest Tagged with ,

Common Permission Error

March 12, 2007 Leave a comment

One extremely important part of using any multi-user Operating System is correctly understanding permissions. Over the past couple years, I have been administering a Linux server with a lot of users, and there is one error that has popped up over and over again.  A lot of users forget or don’t realize that permission to delete a file from a directory is determined by the write flag of the directory, not the write flag of the file.

Take this scenario: Bob is an unprivileged user on a LAMP box and he is hosting a dynamic website.  He wants to allow changes to folders within his public_html directory so he can do things like upload templates, media, etc.  However, the apache user is not Bob, it is something like www-data.  As an unprivileged user, Bob cannot chown or chgrp a directory to a group he doesn’t belong to.  He might think about contacting the sysadmin, but more likely he chmods the directories to be a+w, and is careful to make the files not have the write flag (assuming that this is what determines if a file can be deleted or not). This is an incorrect assumption, and he is leaving his files to be deleted by whoever else has an account on the server.

For example:

bob@lamp:~$ ls -l     #note the test directory has o+w
total 4
drwxrwxrwx 2 bob stupid 4096 2008-07-01 10:27 test

bob@lamp:~$ cd test/

bob@lamp:~/test$ ls -l myfile     #note that myfile does not have o+w
-rw-r–r– 1 lundeen2 stupid 5 2008-07-01 10:28 myfile

bob@lamp:~/test$ su otheruser

otheruser@lamp:~/test$ rm myfile     #other random users are able to delete this file
rm: remove write-protected regular file `myfile’? y

otheruser@lamp:~/test$ ls -l
total 0

There are several ways to handle Bob’s situation.  Bob could ask a privileged user to add him to the www-data group (though this won’t work very well if all the users are part of this group) or he could ask the admin to setattr +i the file to make it undeletable (though he himself could not delete it afterward). A better way would probably be for Bob to use acls (eg setfacl) or to set the sticky bit on the directory (chmod +t).  The sticky bit might be good enough, as it is probably what Bob wanted in the first place – for other users besides himself to be able to write to his directory, but not giving those users a chance to delete his or www-data’s files. Using acls is probably best, but can also be slightly more complicated.

While the behavior of permissions may be obvious to a system administrator, to an average user, it seems it is not.  In my weekly cron scripts I have a  “find / -type d  ( -perm -o+w  -perm 1000 )” to search for all files with this permission.

Filed under Misc Tagged with , ,