为什么 Debian 将“atd”作为“daemon”用户运行?

为什么 Debian 将“atd”作为“daemon”用户运行?
$ ps -aux|grep atd
daemon     800  0.0  0.1  27964  2228 ?        Ss   19:11   0:00 /usr/sbin/atd -f
alan-sy+  7042  0.0  0.0  12780   948 pts/0    S+   20:22   0:00 grep atd

$ /sbin/getpcaps 800
Capabilities for `800': = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read+p

$ ls -l /usr/sbin/atd
-rwxr-xr-x 1 root root 22536 Dec  8  2016 /usr/sbin/atd
# /lib/systemd/system/atd.service
[Unit]
Description=Deferred execution scheduler
Documentation=man:atd(8)

[Service]
ExecStart=/usr/sbin/atd -f
IgnoreSIGPIPE=false

[Install]
WantedBy=multi-user.target

at软件包版本是3.1.20-3.

为什么会atd掉落给daemon用户? Fedora Linux 30 上不会这样做。

atd仍然必须保留所有功能,因为它可以接受任何用户的请求并以该用户身份运行作业,包括root.

用户daemon不应该被使用。如有必要,各个守护进程应该使用自己的用户帐户,以限制安全隐患。 (它大概在这种情况下并不重要,因为内核不允许非 root 用户操作保留任何 root 能力的进程)。

答案1

这可能是由于历史以及 LSB 作者和相关 Debian 维护者之间的意见分歧造成的。base-passwdDebian 中的文档daemon用户说:

一些需要能够写入磁盘上某些文件的非特权守护进程作为 daemon.daemon(portmapatdlambdamoomon和其他)运行。不需要拥有任何文件的守护进程有时会以nobody.nogroup 的身份运行;通常,使用专用用户是更好的做法,更复杂或具有安全意识的守护进程肯定会这样做。守护进程用户对于本地安装的守护进程可能也很方便。

它还说

LSB 1.3 将守护进程列为旧版,并表示:“‘守护进程’UID/GID 被用作守护进程在其下执行的非特权 UID/GID,以限制其对系统的访问。一般来说,守护进程现在应在单独的 UID/ GID 是为了进一步将守护进程彼此分开。”

不过总体来说 Debian 文档允许daemon用户使用。

atd改为使用daemon:daemonroot 代替2005年,此时 LSB 1.3 已经问世几年了。我想从 root 切换到 rootdaemon被认为是特权的充分减少,比添加专用用户(当时很可能涉及管理)更简单,正如你所说,在这种情况下这可能并不重要......

上面链接的错误给出了以下删除到daemon或非 root 用户的理由(该错误建议使用专用组...):

Debian 的 crontab 最近被修改为运行 setgid crontab 而不是 setuid root。由于 at 的需求基本相似,因此它可能会以相同的方式工作,并且在基础中少一个 setuid-root 程序将是一件好事。

相关内容