原来 Linux 里有这么多用户

之前我一直以为，一台 Linux 服务器里通常只有一个用户。

比如我通过 SSH 登录服务器时，看到的是：

root@jp-iij:~#

所以很自然地认为，这台服务器的用户就是 root。

直到刚刚我执行了：

cat /etc/passwd

才发现系统里居然有这么多用户：

rootdaemonbinsyswww-datamessagebussshdvnstatripe-atlastcpdump……

一台服务器为什么会有这么多用户？

这些用户都是谁创建的？

都可以用于登录服务器吗？

后来才明白，Linux 里的“用户”，并不全是现实中的人在使用。

查看 /etc/passwd 时，会看到类似这样的一行：

www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

这一行通过冒号分成多个字段：

用户名:密码占位:UID:GID:说明:家目录:登录 Shell

对应到 www-data：

用户名：www-dataUID：33GID：33家目录：/var/www登录 Shell：/usr/sbin/nologin

最后的：

/usr/sbin/nologin

说明这个用户默认不能正常登录并获得命令行。

所以 /etc/passwd 里虽然有很多用户，但绝大多数并不是给人登录用的，而是给系统服务使用的。

例如：

www-data       用于运行 Nginx 等 Web 服务vnstat         用于运行流量统计服务messagebus     用于运行 D-Bussystemd-timesync 用于系统时间同步_apt           用于 APT 下载软件包sshd           用于 SSH 服务内部隔离ripe-atlas     用于 RIPE Atlas 探针

这些账户更准确地说，应该叫：

服务用户系统用户

为什么服务也要单独创建用户？

既然都是服务器上的程序，直接全部用 root 运行不是更方便吗？

答案是：方便，但非常危险。

假设 Nginx、网站程序、流量统计程序和探针程序全部以 root 身份运行，那么只要其中任何一个程序出现漏洞，攻击者就可能直接获得整台服务器的最高权限。

而如果它们分别以不同的低权限用户运行：

Nginx 使用 www-datavnStat 使用 vnstatRIPE Atlas 使用 ripe-atlas

即使某一个服务出现问题，攻击者能够访问的范围通常也会被限制在该用户拥有权限的范围内。

这就是 Linux 里非常重要的思想：

不同服务使用不同用户，尽量只赋予完成工作所需要的最低权限。

也就是常说的最小权限原则。

哪些用户能正常登录？

我执行了：

awk -F: '$7 !~ /(nologin|false|sync)$/ {print $1, $3, $6, $7}' /etc/passwd

结果只有：

root 0 /root /bin/bash

这说明，在这台服务器的 /etc/passwd 配置中，只有 root 使用正常的 Bash Shell。

其他服务用户大多使用：

/usr/sbin/nologin

或者：

/bin/false

因此它们默认不能像 root 一样通过正常方式获得交互式终端。

需要注意的是，拥有 Bash Shell，也不等于一定可以通过 SSH 登录。

SSH 登录还会受到以下因素影响：

是否设置密码是否配置 SSH 公钥sshd_config 是否允许是否被 AllowUsers 或 DenyUsers 限制

临时切换到 www-data

虽然 www-data 默认不能登录，但 root 可以临时以它的身份启动一个 Bash：

su -s /bin/bash www-data

执行后，提示符变成：

www-data@jp-iij:/root$

这里说明：

www-data  当前用户jp-iij    主机名/root     当前目录$         普通用户提示符

原来 root 的提示符是：

root@jp-iij:~#

其中：

# 表示超级用户$ 表示普通用户

为了确认身份，我执行：

whoamiidpwdls -la

结果是：

www-datauid=33(www-data) gid=33(www-data) groups=33(www-data)/rootls: cannot open directory '.': Permission denied

这说明当前 Shell 的确已经变成了 www-data。

但是出现了一个很有意思的现象：

当前目录仍然是 /root但无法查看 /root 里面的内容

为什么能待在 /root，却不能查看？

这是因为在切换用户之前，root 已经位于 /root。

执行：

su -s /bin/bash www-data

时，新启动的 Bash 继承了原来进程的当前工作目录。

所以 www-data 暂时还停留在 /root。

但当它尝试读取目录内容时，系统会检查权限。

查看 /root 的权限：

ls -ld /root

结果：

drwx------ 14 root root 4096 Jul 11 00:46 /root

其中：

d          表示目录rwx        所有者 root 拥有读、写、进入权限---        root 组没有权限---        其他用户没有权限

www-data 既不是 root，也不属于 root 组，因此它没有权限读取 /root。

这时我先执行：

cd /

离开 /root，然后再执行：

cd /root

系统返回：

bash: cd: /root: Permission denied

这说明切换用户时可以暂时继承原来的当前目录，但一旦离开，再想进入时，就必须重新通过权限检查。

这个现象有点像一个人原本被带进了一个房间，但身份发生变化后，他虽然暂时还站在房间里，却已经失去了重新开门进入和查看房间内容的权限。

www-data 是 Nginx 用户，为什么不能修改网站目录？

既然 www-data 是 Nginx 的用户，

那它应该可以进入并修改 /var/www。

但实际上，Nginx 使用 www-data，不代表它应该拥有整个网站目录的写权限。

很多网站的权限设计是：

root 或部署用户负责修改网站文件www-data 只负责读取网站文件

对于静态网站，Nginx 通常只需要：

进入目录读取 HTML、CSS、JS、图片把内容返回给浏览器

它并不需要修改这些文件。

如果把整个 /var/www 都赋予 www-data 写权限，那么一旦 Nginx 或网站程序被攻击，攻击者就可能直接篡改所有网页文件。

这次操作让我真正理解了 Linux 用户

这次实验之后，我才明白 Linux 里的用户不仅仅是谁登录了服务器。

它还是一种权限边界。

每个进程都必须以某个用户身份运行，每个文件和目录也都有自己的所有者和所属组。

系统通过：

UIDGID文件所有者文件所属组rwx 权限

来决定一个进程能做什么、不能做什么。

所以 Linux 创建这么多服务用户，并不是多余，而是为了把不同服务隔离开。