More About File Attributes

Computers within computers.

Get It Try It

A file system is an entity unto itself. At least on real operating systems it is. File system drivers get requests from the system kernel and they can comply or deny. It's up to them. The file system has to be able to protect itself.

The file system is a shared resource on real operating systems. This means that no ordinary user account can access it directly. The chain of command is something like the following.

The chain of command has to proceed one box at a time from the top down. The user clicks something - a menu item or a toolbar button - to for example save a file. The command goes through to the application where the command is picked up. The application recognises the command and calls a method or function in the application programming interface.

Now you're getting close to the kernel.

The API devolves down until it's in the realm of a shared library or the equivalent. You can find your shared libraries in /usr/lib. Their names all end with the extension dylib ('dynamic library'). There are close to 400 of them on Mac OS X 10.5.

The code in the shared library now contacts the file system driver, forwarding the user's request. A file is to be saved. The driver will have to do a lot more than just find the file. It has to find actual disk sectors for allocation, update the data in the file's status area in the volume control block, and so forth.

And somewhere in there permissions have to be checked as well.

Who is it wants to save a file? What are the file's permissions? The kernel and the file system have to work together to ensure that 'legal' file operations are carried out and that 'illegal' file operations are denied. All files carry three sets of permissions - for the file's owner, the file's group, and everyone else. Does the user have sufficient permissions to write to the file?

The same holds for user requests to read a file or run a file. Or add a file, remove a file, or remove a file - these of course concern permissions on the parent directory instead. The OS kernel and the file system have to work together to make sure the file operations that should succeed do in fact succeed and the file operations that shouldn't succeed don't succeed.

Huge areas of a Unix hard drive are 'out of bounds' for many file operations. This is the operating system protecting itself. Other areas can be made 'out of bounds' by ordinary user accounts. This is the operating system making sure all users respect the rights of others.

But there are occasions when at least some user accounts need to override their own restrictions.

Sudo

Unix has a standard way for user accounts to escalate to root privileges: the 'substitute user' command /usr/bin/su.

SU(1)                     BSD General Commands Manual                    SU(1)

NAME
     su -- substitute user identity

SYNOPSIS
     su [-] [-flm] [login [args]]

DESCRIPTION
     su requests the password for login and switches to that user and group ID after obtaining proper
     authentication. A shell is then executed, and any additional shell arguments after the login name
     are passed to the shell. If su is executed by root, no password is requested and a shell with the
     appropriate user ID is executed.

The difficulty - the danger - with this method is that it's tantamount to being logged in as root. Where any number of booby traps may be placed in one's path. There's a better way to do this.

SUDO(8)                      MAINTENANCE COMMANDS                      SUDO(8)

NAME
       sudo - execute a command as another user

SYNOPSIS
       sudo -K | -L | -V | -h | -k | -l | -v

       sudo [-HPSb] [-a auth_type] [-c class|-] [-p prompt] [-u username|#uid]
       {-e file [...] | -i | -s | command}

       sudoedit [-S] [-a auth_type] [-p prompt] [-u username|#uid] file [...]

DESCRIPTION
       sudo allows a permitted user to execute a command as the superuser or another user, as
       specified in the sudoers file. The real and effective uid and gid are set to match those of
       the target user as specified in the passwd file and the group vector is initialized based on
       the group file (unless the -P option was specified). If the invoking user is root or if the
       target user is the same as the invoking user, no password is required. Otherwise, sudo requires
       that users authenticate themselves with a password by default (NOTE: in the default configuration
       this is the user's password, not the root password). Once a user has been authenticated, a
       timestamp is updated and the user may then use sudo without a password for a short period of
       time (5 minutes unless overridden in sudoers).

The difference is this: su puts you at root level where anything you do could jeopardise the system as a whole (for as long as you stay at that level) whereas sudo substitutes your account for another for one command only (and thereafter exits).

sudo is not a standard part of Unix (su is) but it's found on most Unix systems today including Mac OS X. It was originally developed at SUNY and today is maintained as part of the OpenBSD project. Its 'MO' is fairly straightforward but at the same time rather detailed - it has to prevent unauthorised (rogue) processes from gaining root privileges.

Take the following as an example. The user is going to reset the ownership of all files in the home area. Ordinary user accounts can't change file user ownership (and they certainly can't change the ownership of files owned by root) so sudo would need to be used.

Without sudo (and assuming the user account is the first on the system) the command line would look like this.

$ chown -R 501 ~

There are four (4) command line arguments there. [The '$' is of course the command prompt.]

But running that command 'as is' might run into snags as it's only the superuser (root) who can change file ownerships.

$ sudo chown -R 501 ~

There are now five (5) command line arguments.

sudo's in charge now: it's going to make sure the request is legitimate and there's no skulduggery going on. It will check time stamps, it will check the user's right to even request a privilege escalation, and so forth. [Normally you have to be a member of the group admin to even have a chance.]

# User privilege specification
%admin	ALL=(ALL) ALL

If the request passes all the tests sudo shuffles the command line and sends it out again.

Which is just like it was in the first place (without sudo). But there's one major difference.

$ ls -@ilO /usr/bin/sudo
103301 -r-s--x--x  1 root  wheel  - 211232 Sep 24  2007 /usr/bin/sudo

Maybe this can be read by the Unix rookie; maybe not. There's another way or two to look at it.

sudo's permissions are 4511. The file is owned by root and belongs to the group wheel. Anyone may attempt to run it (but that won't necessarily accomplish anything). Nobody can write to it - not even root - and only root may read it.

That's pretty tight.

But the interesting thing is that '4' in the beginning of the file permissions field. You can see it in the highlight in the image on the right and it's reflected in the tick box for 'Set UID' on the left. It's of course the set user ID bit.

Here's how the thing works.

1. User invokes command line prepended with 'sudo'.
2. System checks file permissions to see whether user can run sudo.
3. sudo checks /etc/sudoers to see if user is allowed to try this trick.
4. sudo checks /var/db/sudo to see if there's a time stamp that's still good.

And so forth. If everything is in order sudo performs the command line shuffle and the command is executed (presumably as root).

But if the command out the one door is the same as came in through the other door then what's the difference?

The difference is in who owns the file /usr/bin/sudo - that and its set user ID bit. The set user ID bit is in the file system. And the kernel picks up this tidbit and acts accordinglly. The set user ID bit resets the effective ID of the process running the program. /usr/bin/sudo is owned by root so whoever runs it effectively becomes root (for that process only).

So sudo essentially becomes a trampoline: commands go in as lowly mortals at one end, bounce a bit, then shoot upwards to the sky like gods. Most importantly: it's the file system and the system kernel working together to protect you. It's this type of cooperative interplay that helps establish the system's security model - that helps keep you secure.

See Also
ACP: Xfile
ACP: Xattr
ACP: Xattrib
ACP: CatInfo
ACP: FileInfo
ACP Users: Managing File Attributes