Strange file ownership with Ubuntu

Question

Normally we know when we create one file in Linux, the file's owner and group will set with the creator. For example, I have one user, usera, after I execute

usera@srv1:$touch 1.txt

I will find the owner of this file will be usera, just like

usera@srv1:$ll
-rw-r--r-- 1 usera usera 0 2012-07-25 14:29 1.txt

But now the result is:

-rw-r--r-- 1 root usera 0 2012-07-25 14:29 1.txt

It seems that not only the touch command, but also others are all have the same problem. For example, if I use vim to create a new file in usera's home, which means this user has permission to create file:

usera@srv1:$ vim a.txt

I can enter edit screen, but cannot save it. The error message is the same as we do not have write permission on that file.

So what happens on our server, the server is Ubuntu 11.04 64bits.

One extra but maybe useful information:
Now all new created users have similar problem. usera is a sudoer, but after I create a new normal user (sudo createuser xxx), assign password and login with this new account, it's the same.

Answer 1

The only reason I can think of that would give such symptoms from the steps you have described, is that touch (and likely a whole slew of other tools) is setuid root, which it is not supposed to be.

Try executing the command ls -lH "$(which touch)" in a terminal; is the first execute bit x or s? If it is s (for example, -rwsr-xr-x), then my gut feeling would be that you are looking at a rooted installation. Note that if your system has been compromised, you can't necessarily trust the output of ls (or for that matter any other tool) to be an accurate representation of reality. The $(which touch) will expand to whatever your shell thinks is the full path to the touch binary, so this will catch the case of a stray touch in a wrong place that happens to come before the real one in your $PATH, and -H makes ls dereference symbolic links (in the case of symlinks, it will show the name of the symlink, but the file properties will be from the symlink target).

If that's not it, from the sounds of it, your system is very seriously broken permissions-wise.

Also remember that vim doesn't actually create the file until you give a save command.

If your system has indeed been compromised, the only real solution is to wipe it clean and rebuild, then carefully restore data and configuration from backups. (You do have backups, right?) In principle, it certainly is technically possible to repair a rooted system, but it tends to be a whole lot more trouble than it's worth, it's extremely easy to miss something, and it certainly is not easier than reinstalling. What that would involve is to boot from trusted, read-only media, mount the existing partitions in their usual places under some alternate root such as /mnt, and go through every single directory, file, permissions bit, etc etc, with a fine-toothed comb, looking for any anomalies and restoring anything even remotely suspicious-looking from a trusted copy. For this, you effectively need an identically set up trusted system to compare against; you cannot trust anything on a compromised host.

Answer 2

It looks like your touch binary is setuid root.

Check this using:

$ ls -l `which touch`
-rwxr-xr-x 1 root root 64192 Jan  8  2012 /bin/touch
#  ^ 

If the marked column has an s instead of an x the file is indeed setuid root. You can fix this by running chmod u-s `which touch` as root (e.g. via sudo).

However, you should consider checking your system for backdoors etc. If random binaries are setuid chances are good someone broke in and replaced harmless binaries with setuid variants that contain some "extra" functionality.

Answer 3

You have read access on a.txt so vim can open it. It should indicate that the file is read-only and warn you when you start making changes (but still allow you to edit the in-memory buffer).

When you try to save it, you don't have write permission so the save fails. You can, of course, tell vim to save it to another filename/directory where you do have write permission.

Answer 4

Yes, The problem is the suid bit for touch, and other problem command.

-rwsr-xr-x 1 root root 64192 Jan 8 2012 /bin/touch

Though we've found the root cause, we have to rebuild the whole system because we don't know how many binary file are affected. And we're still trying to find what cause this. It is only a server for internal use and is not published to internet.

Thank you all for the help.