Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

systemd unit: run as 'daemon' user, not root #6

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

zdzichu
Copy link
Contributor

@zdzichu zdzichu commented May 13, 2015

Debian has been running uptimed as 'daemon' for three years now.
Root permissions are unneccessary. Packagers should ensure that
/var/spool/uptimed is chown'ed on upgrade.

  Debian has been running uptimed as 'daemon' for three years now.
Root permissions are unneccessary. Packagers should ensure that
/var/spool/uptimed is chown'ed on upgrade.
@rpodgorny
Copy link
Owner

hmm, interesting! ...is there any document explaining the policy? (why the daemon user? why not nobody or something like that?)

i can't seem to find anything like this for arch linux (the distro i currently use).

@rpodgorny rpodgorny self-assigned this May 15, 2015
@zdzichu
Copy link
Contributor Author

zdzichu commented May 15, 2015

Debians policy is at: https://wiki.debian.org/SystemGroups:
"daemon: Some unprivileged daemons that need to write to files on disk run as daemon.daemon (e.g., portmap, atd, probably others). Daemons that don't need to own any files can run as nobody.nogroup instead, and more complex or security conscious daemons run as dedicated users."

uptimed needs to own history in /var/spool/uptimed, so it's incompatible with Debian's "nobody". I think creating dedicated user for uptimed would be an overkill.

Arch mainly follows upstream, so if upstream uptimed runs as root, the same is true for Arch. I was unable to find any specific policy.

Fedora did not seem to have policy about "daemon" user, too. I've switched uptimed from running as root to running as daemon in Fedora 23, though.

@gfa
Copy link

gfa commented Dec 2, 2016

If i had to made the switch to a non-root user, I'd create a new user (_uptimed) instead of using daemon but that boat sailed long ago for Debian, so yeah pls accept this PR

@rpodgorny
Copy link
Owner

hmm, has this advanced/changed in debian/fedora meanwhile?

also, if ownership of /var/spool/uptimed is to be changed, shouldn't there a systemd-tmpfiles snippet as well?

@zdzichu
Copy link
Contributor Author

zdzichu commented Dec 4, 2021

Current state:

@xtaran
Copy link

xtaran commented Feb 3, 2023

Hi,

sorry for chiming in late. Did seem to have overseen the according notification and stumbled over the nick highlight just by accident.

@rpodgorny wrote:

hmm, has this advanced/changed in debian/fedora meanwhile?

@zdzichu wrote:

  • Debian continues to run uptimed as daemon. No change here in recent years. @xtaran could you confirm?

I can confirm that there were no changes wrt. the user uptimed is running under on Debian since I took over the uptimed Debian package. And I also don't intend to change this as it works well that way.

@rpodgorny wrote:

also, if ownership of /var/spool/uptimed is to be changed, shouldn't there a systemd-tmpfiles snippet as well?

No. /var/spool/ is not a directory that is handled by systemd-tmpfiles. It only handles volatile directories. /var/spool/ is not volatile.

The ownership of that directory is set in Debian's postinst script.

@zdzichu
Copy link
Contributor Author

zdzichu commented Jul 22, 2023

I think it is warranted to merge this PR now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants