1
$ 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 package version is 3.1.20-3.

Why does atd drop to the daemon user? It does not do so on Fedora Linux 30.

atd still has to retain all capabilities, because it can accept requests from any user and run jobs as that user, including root.

The daemon user is not supposed to be used. Individual daemons are supposed to use their own user accounts if necessary, to limit security compromises. (It probably does not matter in this case, because the kernel does not allow non-root users to manipulate processes which retain any root capability).

1 Answer 1

1

This is probably down to history, and difference of opinion between the LSB authors and the Debian maintainers involved. The base-passwd documentation in Debian says of the daemon user:

Some unprivileged daemons that need to be able to write to some files on disk run as daemon.daemon (portmap, atd, lambdamoo, mon, and others). Daemons that don't need to own any files sometimes run as nobody.nogroup instead; it is generally better practice to use a dedicated user, and more complex or security-conscious daemons certainly do this. The daemon user is also handy for locally installed daemons, probably.

It does also say that

LSB 1.3 lists daemon as legacy, and says: "The 'daemon' UID/GID was used as an unprivileged UID/GID for daemons to execute under in order to limit their access to the system. Generally daemons should now run under individual UID/GIDs in order to further partition daemons from one another."

However overall the Debian documentation allows the daemon user to be used.

atd was changed to use daemon:daemon instead of root in 2005, by which time LSB 1.3 had been out for a few years. I imagine that switching from root to daemon was perceived as a sufficient reduction in privilege, was simpler than adding a dedicated user (which might well have involved administrivia at the time) and as you say it probably doesn’t matter in this case...

The bug linked above gives the following reasoning for dropping to daemon, or rather to a non-root user (the bug suggested a dedicated group...):

Debian's crontab was recently modified to run setgid crontab rather than setuid root. Since at's needs are substantially similar, it could probably work the same way, and one less setuid-root program in base would be a good thing.

1
  • 1
    It sounds like at is dancing with effective/real UIDs, so that the filesystem writes it performs are done with daemon privileges, but it can switch back to root when it needs to "impersonate" a specific user. I had forgotten how that works.
    – sourcejedi
    Jul 28, 2019 at 20:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .