通常我们知道，当我们在Linux中创建一个文件时，该文件的所有者和所属组将由创建者设置。例如，usera我执行后有一个用户 ，
usera@srv1:$touch 1.txt
我会发现这个文件的所有者将是usera，就像
usera@srv1:$ll
-rw-r--r-- 1 usera usera 0 2012-07-25 14:29 1.txt
但现在的结果是：
-rw-r--r-- 1 root usera 0 2012-07-25 14:29 1.txt
看来不仅是touch命令，其他的也都有同样的问题。例如，如果我使用vim在usera的家中创建一个新文件，则意味着该用户有创建文件的权限：
usera@srv1:$ vim a.txt
我可以进入编辑屏幕，但无法保存。错误消息与我们没有对该文件的写入权限相同。
那么我们的服务器上发生了什么，服务器是 Ubuntu 11.04 64 位。
一个额外但可能有用的信息：
现在所有新创建的用户都有类似的问题。usera是一个sudoer，但是当我创建一个新的普通用户（sudo createuser xxx），分配密码并使用这个新帐户登录后，它是一样的。
答案1
我能想到的唯一原因会出现这种症状从你所描述的步骤，是touch（并且可能还有大量其他工具）是 setuid root，但它不应该是。
ls -lH "$(which touch)"尝试在终端中执行命令；是第一个执行位x还是s？如果是s（例如，-rwsr-xr-x），那么我的直觉是您正在查看 root 安装。注意如果如果您的系统已受到损害，您不一定可以相信ls（或任何其他工具）的输出是现实的准确表示。将$(which touch)扩展为您的 shell 认为是二进制文件的完整路径的任何内容touch，因此这将捕获错误位置中的流浪情况touch，该位置恰好出现在您的 中的真实路径之前$PATH，并-H取消ls引用符号链接（在这种情况下）符号链接，它将显示符号链接的名称，但文件属性将来自符号链接目标）。
如果不是这样，从声音来看，您的系统在权限方面受到了非常严重的破坏。
另请记住，vim在您发出保存命令之前，实际上并不会创建文件。
如果您的系统确实受到损害，唯一真正的解决方案就是将其清除并重建，然后小心地从备份中恢复数据和配置。 （你确实有备份，对吧？）原则，从技术上来说，修复 root 系统当然是可能的，但它往往比它的价值要麻烦得多，而且很容易错过某些东西，而且它肯定不比重新安装容易。这将涉及到从值得信赖的、只读介质，将现有分区挂载到某个备用根目录（例如 /mnt）下的常用位置，并仔细检查每个目录、文件、权限位等，查找任何异常情况并从受信任的副本中恢复任何看似可疑的内容。为此，您实际上需要一个相同的设置值得信赖的比较系统；你不能相信任何事情在受感染的主机上。
答案2
看起来您的touch二进制文件是 setuid root。
使用以下命令检查这一点：
$ ls -l `which touch`
-rwxr-xr-x 1 root root 64192 Jan 8 2012 /bin/touch
# ^
如果标记的列有一个s而不是一个，则x该文件确实是 setuid root。您可以通过chmod u-s `which touch`以 root 身份运行来解决此问题（例如通过sudo）。
但是，您应该考虑检查您的系统是否有后门等。如果随机二进制文件是 setuid，那么很可能有人闯入并用包含一些“额外”功能的 setuid 变体替换无害的二进制文件。
答案3
您拥有 a.txt 的读取权限，因此 vim 可以打开它。它应该表明该文件是只读的，并在您开始进行更改时发出警告（但仍然允许您编辑内存缓冲区）。
当您尝试保存它时，您没有写入权限，因此保存失败。当然，您可以告诉 vim 将其保存到您有写入权限的另一个文件名/目录中。
答案4
是的，问题是 touch 的 suid 位和其他问题命令。
-rwsr-xr-x 1 root root 64192 2012 年 1 月 8 日 /bin/touch
虽然我们已经找到了根本原因，但我们必须重建整个系统，因为我们不知道有多少二进制文件受到影响。我们仍在努力找出造成这种情况的原因。它只是一个供内部使用的服务器，不会发布到互联网上。
谢谢大家的帮助。