Systemctl doesn't work well

[Bedotech]

Hi all, when i run for the first time Caddy installed with this role the service never started, this happens on Ubuntu 16.04, this is because Caddy tries to access on many directories under the home at least when the configs are changed, for example in have to comment this line:

; Hide /home, /root, and /run/user. Nobody will steal your SSH-keys.
; ProtectHome=true

I don't know why but I have to change this after I modify caddy config file... any suggestion? because the ProtectHome make sense.

[joelnb]

Would be easier to help if you could post your entire caddy.service file (should be in /etc/systemd/system/caddy.service). Also, have you manually changed the service at all? Are you using the default options for the role? Which user's home directory did caddy try to access?

If you do not have the CADDYPATH set in the systemd unit then caddy will try and use $HOME/.caddy/ so that could explain it but this role always sets that to the value of caddy_certs_dir (which has a default value of /etc/ssl/caddy). This should result in these lines in your caddy.service file:

Environment=CADDYPATH=/etc/ssl/caddy
...
ReadWriteDirectories=/etc/ssl/caddy

[chrisglass]

I am having the same issue, and I suspect the git module is to blame, when trying to pull from a private repository.

A minimal Caddy file reproducer snippet for me seems to be:

git {
  repo git@example.com/repo-that-i-can-clone-by-hand-just-fine.git
  key /etc/caddy/caddy_rsa # This exists, is owned by www-data:www-data and is chmod 600
}

Note that the www-data user created by this playbook does not have a $HOME set (nor does one exist on disk).

[chrisglass]

I meant to add, but pressed enter too fast:

The role is cloned from master and is not customised in any way. The machine is a vanilla install of Ubuntu 18.04.

Cloning from a public repo (over HTTPS) works for me:

git {
  repo https://blah.com/blah.git
}

[chrisglass]

Workaround, setting:

caddy_systemd_protect_home: False

in the playbook allows me to deploy on 18.04 using the latest version of the role.

[joelnb]

Interesting @chrisglass after making that change do you see any files being created on disk in the home directory? I know you said that the www-data user created by this role does not have a home but on my system it does - /home/caddy - so I would look there for any files which may be created:

~ getent passwd | grep www-data
www-data:x:33:33:www-data:/home/caddy:/usr/sbin/nologin

If I have time I'll try and reproduce this but thanks for your work on the issue so far.

[chrisglass]

I seems the only thing that is being written in /home/caddy between an unsucessful service start and a successful service start is the .ssh folder - and the known_hosts files, as you would expect for a git checkout over SSH.

With home protection (service fails): https://gist.github.com/chrisglass/10977648ae32fcd430c8cf0f2c854882
Without home protection (service running): https://gist.github.com/chrisglass/d8469d75a41a76e64032d111b571307b

[joelnb]

Ah good work, that makes sense then. I don't really see any way around that. Seems like the only way to change the known_hosts path is using an SSH config option & I don't see that as something this role should be getting involved in (especially given that it's only an issue if you are using the git middleware with SSH).

Perhaps a documentation change to point out that caddy_systemd_protect_home should always be turned off when using the git middleware + ssh would be the best option. What do you think?

[chrisglass]

In the context of this ansible role, I think it makes little sense to have protectHome set to true at all.

I understand the decision in caddy (upstream) case where you can't guarantee what the home(s) will look like in the system, but here we know that $HOME is safe since we create the user in the first place.

Besides, normal UNIX permissions are still enforced, and the www-data user still can't read SSH keys in neighbouring /home directories.

So, I would either:

• Disable caddy_systemd_protect_home by default since it doesn't buy us much security at all in this role.
• Disable caddy_systemd_protect_home in case the git keyword uses an SSH URL, and document the behaviour.
• restrict the reading and writing to just .ssh in $HOME, but that kind of defeats the purpose of having the security in the first place since .ssh is exaclty where keys are stored 😄

[joelnb]

I think you're right & I would support disabling that option for the reasons you explained.

@lbischof would you mind adding your thoughts when you have the time?