Unix Tip: Changing chown

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

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine