$ 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-passwd
Debian 中的文档daemon
用户说:
一些需要能够写入磁盘上某些文件的非特权守护进程作为 daemon.daemon(
portmap
、atd
、lambdamoo
、mon
和其他)运行。不需要拥有任何文件的守护进程有时会以nobody.nogroup 的身份运行;通常,使用专用用户是更好的做法,更复杂或具有安全意识的守护进程肯定会这样做。守护进程用户对于本地安装的守护进程可能也很方便。
它还说
LSB 1.3 将守护进程列为旧版,并表示:“‘守护进程’UID/GID 被用作守护进程在其下执行的非特权 UID/GID,以限制其对系统的访问。一般来说,守护进程现在应在单独的 UID/ GID 是为了进一步将守护进程彼此分开。”
不过总体来说 Debian 文档允许daemon
用户使用。
atd
改为使用daemon:daemon
root 代替2005年,此时 LSB 1.3 已经问世几年了。我想从 root 切换到 rootdaemon
被认为是特权的充分减少,比添加专用用户(当时很可能涉及管理)更简单,正如你所说,在这种情况下这可能并不重要......
上面链接的错误给出了以下删除到daemon
或非 root 用户的理由(该错误建议使用专用组...):
Debian 的 crontab 最近被修改为运行 setgid crontab 而不是 setuid root。由于 at 的需求基本相似,因此它可能会以相同的方式工作,并且在基础中少一个 setuid-root 程序将是一件好事。