DirectNET

OS X | UNIX

The Unexplained Disappearance of Janice's File

Melkor is unable to write to or change 'file' for which only janice has write permission. But melkor has write permission for the directory that contains 'file'. Having write permission for a directory means you can change it - i.e. create and remove files within that directory. The point being that having write access to a directory allows one to delete a file from the directory no matter what the permissions for the file.

You may have in your home directory a file owned by 'root' with no permissions for anyone. You can remove it. You can't view it or change it, but you can remove it. This may seem odd, but the reason is that you are not changing the file itself, only the directory. You are removing the directory entry for that file, and so the file vanishes and the disk space it occupied becomes free. But you are only changing only the directory, not the file.

This behaviour may not always be desirable. For example, the shared directory /Users/Shared has read and write permission for everybody. But it is not desirable that users have a licence to arbitrarily delete each other's files.

Enter the sticky bit.

Getting Sticky

The secret to preventing unwanted file removals lies in making a directory 'append only'. Files can be added but not removed by unprivileged users. Such a directory is termed a sticky directory. A sticky directory has the sticky bit set.

For example, the Shared directory is sticky.

% ls -al /Users
total 0
drwxrwxrwt  11 root     wheel         330 Jul  7 19:36 Shared
...

Stickiness is indicated by a 't' at the end of the permissions. 'ls' replaces 'x' in the others permissions triplet with 't'.

How is the Sticky Bit Set?

As with all other permissions, 'chmod' is used to set and clear the sticky bit.

% mkdir test
% ls -ald test
drwxr-xr-x   2 melkor   staff          24 Jul 12 16:08 test
% chmod u+t test
% ls -ald test
drwxr-xr-t   2 melkor   staff          24 Jul 12 16:08 test

The sticky bit is set.

% chmod u-t test
% ls -ald test
drwxr-xr-x   2 melkor   staff          24 Jul 12 16:08 test

The sticky bit is cleared.

You may also use 'g+t' which has exactly the same effect; 'o+t' has no effect.

Exactly Who?

A file in a sticky directory may be removed only by:

• the owner of the file
• the owner of the directory

providing they have write access for the directory,

and (of course):

• the super-user.

Sticky Files

Executable files can also be sticky, which has to do with sharing and memory management. In Mac OS X this is depreciated and is taken care of by the virtual memory system.

Why 't' for Sticky ?

Simply because the 's' nomenclature was already taken by the 'Set ID on execution' bit - covered later in this lesson.

Little 't' Big 'T'

When 'ls' lists a sticky directory it replaces 'x' with 't' in the others permissions.

What if 'x' was not set - how does 'ls' differentiate these two cases? It uses 'T' instead of 't'

't' means sticky and others executable

'T' means sticky and not others executable.

Numeric User and Group IDs

Thus far we have thought of user and group IDs in terms of textual names - melkor, janice, root, staff, admin, wheel. Unix thinks of them in terms of numeric IDs - User ID or UID, and Group ID or GID.

Associated with each user is a unique UID; and associated with each group is a unique GID. Your user name is only really used for authentication when logging in. If your user name exists, and you give the correct password, then you are granted the use of a UID and a GID. From here on your UID identifies you. All Unix permissions are based on UID and GID - not on the textual names. This is because the user owner and group owner information for a file is recorded only as numeric IDs.

The textual versions are for your convenience.

You can use the 'id' command to view this information:

% id
uid=502(melkor) gid=20(staff) groups=20(staff), 80(admin)

This command lists my UID, my primary GID, and all the groups to which I belong.

Clones

Because Unix relies on numeric IDs, not names, two users with the same UID, but different names, are in viewed as the same user and have identical file system permissions.

Similarly, two groups with different names but the same GID are viewed as the same group.

The 's' Bits

Let's examine the sudo executable:

% ls -al /usr/bin/sudo
---s--x--x 1  root  wheel ..... /usr/bin/sudo

Because of the nature of this command it has high security settings. Also, notice that the 'x' in the user permissions shows as 's'. This means that the set user id on execution (S-UID) bit is set. The file is still executable by the user owner, as well as by all others.

When 'sudo' is executed, instead of inheriting the UID of the user by whom it was executed, 'sudo' inherits the UID of the user who owns the file - in this case root. As far as the file system is concerned, the super-user executed 'sudo' and it runs with root permissions. The inherited GID(s) is unaffected.

'sudo' in turn executes as root the command it was given, passing on its inherited root UID.

To set the S-UID bit, use (you guessed it) chmod:

% touch a-script
% ls -al a-script
-rwxr-xr-x 1  melkor  staff ... a-script
% chmod u+s a-script
% ls -al a-script
-rwsr-xr-x 1  melkor  staff ... a-script

Now any user running 'a-script' will run as melkor.

There are security implications in setting the S-UID bit. If 'a-script' were written to delete some of melkor's files, any user who can execute 'a-script' can now delete those files regardless of their native permissions. Worse still, if 'a-script' had write permission for others, any user could modify the script as they wish, and effectively gain complete visibility to, and control over, melkor's files. Scary!

If you wish to set a command to execute with the GID of the group that owns the file, set the set group id on execution (S-GID) bit with:

% chmod g+s a-script 
% ls -al a-script
-rwsr-sr-x  1 melkor  staff ..... a-script

'a-script' will now execute with the permissions of user melkor, group staff, no matter who executes it.

Naturally, only the super-user and the file owner may set the S-UID and S-GID bits.

S-OID?

The command:

makes no sense and has no effect on the file permissions.

Little 's' Big 'S'

When 'ls' lists a S-UID or S-GID enabled file, 's' replaces 'x' in the user and/or group owner permissions.

What if 'x' was not set - how does 'ls' differentiate these two cases?

It uses 'S' instead of 's'

's' means S-UID/G-UID set and user/group executable

'S' means S-UID/G-UID set but not user/group executable.

Security Breach!

S-UID and root are a dangerous combination. Imagine an editor owned by root that also has the S-UID bit set.

Anyone who can execute the editor will do so as root and can therefore see and change any file in the file system.

root UID, GID

The super-user has a UID of 0. Its primary group is wheel, which has a GID of 0.