Problem with chown

fgagnon · 04-03-2005, 04:22 PM

hi,
Can some one explain to me why the las command (chown) give the error? I am the owner of the file, I should be able to transfer ownerhsip to whomever I want... no?

bart 17:16:05 ~> echo hello >a.txt
bart 17:16:20 ~> chown mail a.txt
chown: changing ownership of `a.txt': Operation not permitted
bart 17:16:41 ~> ls -al a.txt
-rw-r--r-- 1 fgagnon fgagnon 6 Apr 3 17:16 a.txt
bart 17:16:46 ~> chmod 777 a.txt
bart 17:16:55 ~> chown mail a.txt
chown: changing ownership of `a.txt': Operation not permitted

thanks

mjrich · 04-03-2005, 04:52 PM

At a guess, mail is a group, not a user on your system.

Cheers,

mj

fgagnon · 04-03-2005, 05:26 PM

No, there is indeed both a group and user named 'mail'.

bart 18:22:02 ~> grep mail /etc/passwd
mail:x:8:8:mail:/var/mail:/bin/sh
bart 18:22:14 ~> grep mail /etc/group
mail:x:8:

However, if I switch to root, I can change the owner without a problem:

bart 18:23:08 ~> sudo chown mail a.txt
Password:
bart 18:23:48 ~> ls -al a.txt
-rwxrwxrwx 1 mail fgagnon 6 Apr 3 17:16 a.txt

strange...

alienDog · 04-03-2005, 05:43 PM

It's actually very rare in unix like systems that you can give away the ownership of files. There are a few that support it, but in linux it can't be done (except as root naturally). It's stupid really, but what can you do but learn to live with it.

fgagnon · 04-03-2005, 05:52 PM

This does sound like a limitation, but I can live with it...

However, this problem came up while I was setting up exim 4.5 on my system. At some point, it generates some file and then attempts to chown of those files to the actual recipient. So does it mean that I have to run exim as root? This seems like a major security risk? Most system run exim as mail, but I don't know how they get around this problem.

fg

alienDog · 04-03-2005, 06:00 PM

All the mailservers are run as root in all the systems (even the ones that let you give away files), there is no other way of doing it. They can indeed be a security risk (sendmail has a particularily bad name when it comes to this, though new versions are considered to be quite secure). Exim is to my knowledge one of the most secure ones.

mjrich · 04-03-2005, 06:43 PM

From a bit of reading, it makes a bit more sense that ordinary users can't give away file ownership -

Quote:

In earlier versions of UNIX, all users could run the chown command to change the ownership of a file that they owned to that of any other user on the system. This let them "give away" a file. The feature made sharing files back and forth possible, and allowed a user to turn over project directories to someone else.

Allowing users to give away files can be a security problem because it makes a miscreant's job of hiding his tracks much easier. If someone has acquired stolen information or is running programs that are trying to break computer security, that person can simply change the ownership of the files to that of another user. If he sets the permissions correctly, he can still read the results. Permitting file give-aways also makes file quotas useless: a user who runs out of quota simply changes the ownership of his larger files to another user. Worse, perhaps, he can create a huge file and change its ownership to someone else, exceeding the user's quota instantly. If the file is in a directory to which the victim does not have access, he or she is stuck.

...Practical Unix & Internet Security, Garfinkel & Spafford, O'Reilly

That said, some systems (Caldera ?) do have a 'chown' group that allows people to do just that.

Cheers,

mj

Dark_Helmet · 04-03-2005, 08:19 PM

In addition to the text mjrich quoted, think of this:

1. Suppose a cracker gets access to a user-land account (maybe the user forgot to log out, the cracker got the user's password and user ID, whatever).
2. Now this cracker copies over the source for the passwd program to this user account.
3. The code is compiled, and the cracker gives execute permissions to everybody (owner, group, others)
4. The cracker sets the SUID bit
5. Then chown is used to give the executable to root

Bingo. The cracker now has the ability to change the password of anybody on the system.

I'm sure there are far more subtle/sinister ways to exploit giving away files, but the example above means the system is compromised as soon as any account is compromised. Being able to give away files is not such a good idea.

alienDog · 04-03-2005, 08:27 PM

Hmm... true, but the suid could be cleared when the file is given away. I imagine that systems that allow giving away files operate that way (not sure though).

Dark_Helmet · 04-03-2005, 09:35 PM

I didn't see anything in the chown man page about stripping away SUID. I can't experiment at the moment to know for sure.

Even if that is the case, the next step would be for the cracker to compile his own, modified version of chown to not strip the SUID.

As I think about it, the only effective way to prevent this sort of exploit is inside the kernel's filesystem support. Specifically, only root should have write access to the ownership and group ownership information in the filesystem. I imagine that's the way things are, but can't point to any references to say one way or the other.