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.

you've missed a step. what happened between the first ll listing and 'But now the result is"?
–
casJul 25 '12 at 7:13

What I mean is that I only execute one ll, and want the result is the first one, but the actual output is the latter. I do not execute any chown commands.
–
BenjaliuJul 25 '12 at 7:26

Does the problem only occur when you create a file with touch, or regardless of how you create the file? if the former, has somebody made /usr/bin/touch setuid root? please show output of ls -l /usr/bin/touch.
–
casJul 25 '12 at 8:27

actually, Michael K's suggestion of ls -lH $(which touch) is better - that gets the first touch in your path (which may not be /usr/bin/touch), and dereferences any symlinks.
–
casJul 25 '12 at 8:31

the extra information isn't very useful. what would be useful would be to post the output of ls -lH "$(which touch)" as has been requested several times. If you want help diagnosing a problem then you need to provide the diagnostic info when it is requested.
–
casJul 25 '12 at 9:15

4 Answers
4

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.

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.

But the question is that the user created the file so how it is possible that the user ID is root ??
–
bobJul 25 '12 at 7:19

1

It shouldn't be possible. Are you sure you're running as 'usera' and haven't su-ed to root (with a messed up PS1 prompt string?). otherwise i'd suspect either malicious or clueless activity, a badly written cron-job, or that the system is so broken/corrupted that it needs to be rebuilt.
–
casJul 25 '12 at 7:22

I do suspect that the server was hacked or mis-configured. I know the simplest way is to rebuild the system, but I hope if anyone has similar experiences and can provide us an easier solution.
–
BenjaliuJul 25 '12 at 7:41

1

If the server has been rooted, the only real solution is to wipe and rebuild. The alternative is to boot from alternative, trusted, read-only media, and go through every directory, every file, every permissions bit with a fine-toothed comb, compare the binaries to trusted copies, and selectively replace anything suspicious. Basically, you'd need an identical system from "before" the breach to compare against (you cannot trust anything on a compromised host). Technically it can be done, but is extremely rarely worth anything remotely like the effort (and it certainly isn't easier).
–
Michael KjörlingJul 25 '12 at 7:50

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.

A side note: the setuid root bit for /bin/touch is not the root cause, as you state yourself by saying "we're still trying to find what cause (sic) this". Jan 8 2012 sounds awfully new for something in Ubuntu 11.04 that doesn't really ever need to be updated. (How many bugs can there be in touch?) It sounds to me like you should be lucky that whoever compromised your system apparently didn't cover their tracks very well. Any host connected to the Internet (even if it is only used by a single person) gets bombarded with all kinds of attacks all the time, that's a fact of life these days.
–
Michael KjörlingJul 26 '12 at 8:06