search

caddyserver / dist

Resources for packaging and distributing Caddy
Apache License 2.0
119 stars 118 forks source link

init: enable systemd DynamicUser support #89

Closed Xe closed 2 years ago

Xe commented 2 years ago

This allows people to set up Caddy on a machine without having to create a dedicated user or group. The user and group will be dynamically allocated by systemd. See 1 or 2 for more information.

francislavoie commented 2 years ago

Does this mean that it creates the caddy user only if it doesn't already exist?

Keep in mind that this service file is included in our deb and rpm packages, so I just want to be careful here.

Also, the caddy user's typical home is /var/lib/caddy. Why /var/lib/private/caddy ?

carlwgeorge commented 2 years ago

Does this mean that it creates the caddy user only if it doesn't already exist?

Basically yes, but it's a dynamic user that doesn't work the same as a static user. The UID and GID are recycled after the unit is stopped. That doesn't work well for webservers where it's common to grant the webserver user read access to your website content (or just have the webserver user own the files outright). That right there is reason enough not to merge this. The directive description even calls this out.

However, UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by these users/groups around, as a different unit might get the same UID/GID assigned later on, and thus gain access to these files or directories.

Additionally, systemd has this neat "feature" where it silently ignores directives it doesn't understand. That means deploying the unit file like this on an older systemd would result in the directives being ignored. I get why it's like that but it can lead people to believe they are using a directive when it's not in effect. That is confusing for sysadmins and best avoided.

mohammed90 commented 2 years ago

Does this mean that it creates the caddy user only if it doesn't already exist?

Basically yes, but it's a dynamic user that doesn't work the same as a static user. The UID and GID are recycled after the unit is stopped. That doesn't work well for webservers where it's common to grant the webserver user read access to your website content (or just have the webserver user own the files outright). That right there is reason enough not to merge this. The directive description even calls this out.

However, UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by these users/groups around, as a different unit might get the same UID/GID assigned later on, and thus gain access to these files or directories.

I think we tried or tested this briefly and learned that it might not be able to serve/read the directories which it's supposed to be able to. I'm also not sure whether it'll have funny interaction with unix sockets.