September 22, 2004, 5:19 PM — If you have tried to give away any files lately on any of your Unix systems (i.e., without first becoming root), you may have been surprised to learn that you can't. On most Unix systems today, any non-root user
is likely to get errors such as these when he or she tries to change ownership on a file:
$ chown sbob *ksh chown: acc_cfg.ksh: Not owner chown: checkout.ksh: Not owner |
The error message "Not owner" doesn't necessarily mean what it says. You may be the owner of the file(s) in question and still not be able to change the owner to some other user.
For many of us, this inability to give away our files contradicts what we remember from our early days with Unix. We may even scratch our heads and mutter "Wait! I used to be able to do this!". So, let's take a look at when chown works, why it only works sometimes and what kind of control we have over how the chown command operates.
Who owns chown?
These days, chown, the command that purports to change the owner, or both the owner and group, associated with a file is commonly restricted to the superuser. That is, only root is able to take a file that belongs to one user and make it belong to another user. The reason behind this change in how the chown command works is one of fundamental system security. A restrictive chmod command provides for non-repudation (i.e., a user cannot claim that a file that he creates is not his). Even more importantly, a restrictive chmod keeps a user from creating a script, turning on suid and then giving the file to root with chmod.
On many Unix systems, therefore, chown does not allow anyone but root to change onwership of a file. On Solaris, this behavior can be changed. If you put the command "set rstchown=0" in the /etc/system file and reboot, chown will then change its behavior and permit any user to change ownership on or "disown" his or her files.
What about security?
When the chown command can be used by any normal user, it generally adjusts its behavior in one other way that prevents the command from being abused. It strips the suid and sgid bits, keeping the file from being assigned superuser privilege to anyone who runs it. Here's an example.
First, let's create a tiny script that looks like this:
--------------------------- cut here ---------------------------
#!/usr/bin/bash
cat /etc/shadow
--------------------------- cut here ---------------------------
Under normal circumstances, a non-root user cannot examine the contents
of the /etc/shadow file, so let's see if we can trick the system into showing it to us.
Next, we set the permission on the file so that all three special bits -- the suid and sgid bits -- are turned on:
$ chmod 6755 tryme
Then, we look at the file to verify that the intended permissions have been set:
$ ls -l tryme -rwsr-sr-x 1 shs staff 33 Sep 21 09:53 tryme
Finally, we try giving the file to the superuser and examine the results:
$ chown root:other tryme $ ls -l tryme -rwxr-xr-x 1 root other 33 Sep 21 09:53 tryme
From this example, we can see that the suid and sgid bits are stripped. Any user attempting to run the script will get this response:
$ ./tryme
cat: cannot open /etc/shadow
This is what we want, of course. Were it easy to trick the OS into giving us root privilege to display files normally restricted to root, we could do far worse things as well -- such as building a script with
suid root privilege that execs a shell.
Fortunately, most (but not necessarily all) versions of Unix will behave in this way -- stripping a file of its setuid and sgid bits whenever a file is chown'ed. If you are tempted to allow normal suers to disown
their files, it's a good idea to know just how the chown command is going to behave.
