Nextcloud Caddy general configuration

Help
1

1. Caddy version (caddy version):

2.3.0

2. How I run Caddy:

a. System environment:

Debian 10 Buster with Caddy as a service running under the “caddy” user
systemd, no Docker
php-fpm 7.4.16 running as user caddy:caddy
Nextcloud root being /var/www/nextcloud permissions caddy:caddy 700
Nextcloud data directory being /var/nc_data with permissions caddy:caddy 770
No plans to run other webservers like e.g. Apache at the moment. Would like to stay with Caddy!

b. Command:

sudo systemctl start caddy

c. Service/unit/compose file:

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

d. My complete Caddyfile or JSON config:

nc2-test.hfw18 {
        root * /var/www/nextcloud
        file_server
        encode gzip zstd
        tls internal
#       php_fastcgi 127.0.0.1:9000 {
        php_fastcgi unix//run/php/php7.4-fpm.sock {
                env front_controller_active true
        }

        log {
                output file     /var/log/caddy_nc.log
                format single_field common_log
        }

        header {
                Strict-Transport-Security max-age=31536000;
        }

        redir /.well-known/carddav /remote.php/dav 301
        redir /.well-known/caldav /remote.php/dav 301

        # .htaccess / data / config / ... shouldn't be accessible from outside
        @forbidden {
                path    /.htaccess
                path    /data/*
                path    /config/*
                path    /db_structure
                path    /.xml
                path    /README
                path    /3rdparty/*
                path    /lib/*
                path    /templates/*
                path    /occ
                path    /console.php
        }

        respond @forbidden 404
}

3. The problem I’m having:

My test with Nextcloud on Caddy runs pretty well so far.

I have some general questions left, which would be nice if someone would answer as I am quite a newbie:

Is it generally a good idea to switch php-fpm to run as the caddy user and change ownership of the /var/www directory to the caddy-user? In a standard case this would all be the www-data user. So I decided to switch it all over. Any downsides with this? Suggestions?

Is it maybe a better idea to move the nextcloud root directory to somewhere else e.g. /srv/www or /usr/share/www ?

Or would it be a good idea to switch Caddy to run as www-data?

Thanks for your thoughts and ideas!

4. Error messages and/or full log output:

No errors so far.

5. What I already tried:

Already got it going, but eager to learn more. :wink:

6. Links to relevant resources:

2

I should probably update the apt repo to set up the Caddy user to be part of the www-data group if it exists, but I haven’t gotten around to that yet. You can do that yourself quite easily, for now :+1:

1 Like
3

Not sure if adding the caddy user to the www-data group will be sufficient as the nextcloud directory has 750 permissions and the webserver user needs wright permissions in that directory as far as I know. Ok, I could turn it to 770 of course…

But do you see any security concerns in switching it all to the caddy user?

4

In cases where the PHP process is divorced from the web server (i.e. Caddy), the web server should require no write permission. PHP, however, would.

If PHP runs as www-data:www-data, the directory is owned by www-data:www-data, with permissions 750, and Caddy runs as caddy:caddy, and caddy is a member of www-data, then:

  • Caddy can read files from the disk and send them to PHP
  • PHP can read and write on the disk

Which is an ideal setup, as a matter of principle. From a security perspective, principle of least privilege dictates that giving the web server process itself permissions it doesn’t need (write) is not desirable. I’d rate exploitation of this as highly unlikely, but again that judgement is solely based on the principle.

2 Likes
5

Thanks for clarification on this!

1 Like
6

This topic was automatically closed after 30 days. New replies are no longer allowed.