Run as unprivileged user

[michaelbaudino]

Hi,

This webdav module is working extremely well with a few lines of configuration, congratulations for the awesome job :trophy:

One issue I'm facing now is that file manipulations done via webdav are done with the permissions of the user Caddy runs as (which is root when using Docker).

I'd love to be able to configure another user to perform file manipulations as, probably following the user[:group] or uid[:gid] format like this:

webdav.{$BASE_URL} {
  webdav {
    root /share/
    user mike:mike
  }
}

Using Docker or Docker Compose, it would even be configurable like this:

webdav.{$BASE_URL} {
  webdav {
    root /share/
    user {$UID}:{$GID}
  }
}

Do you think that might be considered? Or should I gosu/su-exec the whole Caddy server instead? Or do you recomment another solution?

Thanks a lot in advance :pray:

[mholt]

I am not too familiar with Docker, but I do believe this is something that should be handled outside Caddy; i.e. it's not Caddy's job to determine who to run as; and I strongly hesitate to add unix-specific code into Caddy or its modules that should work equally well cross-platform. Users and permissions are a system issue, not a web server concern. AFAIK you can run processes without being root with Docker, and apparently this is sometimes even recommended. I'd rather not introduce that complexity into this project.

I think there's a --uid flag you can pass with the Docker command to specify the user ID to run as.

Not sure if that is helpful but maybe it will give you some ideas of what to search for.

[pgaskin]

If you need more limited permissions for webdav only, you could run a second unprivileged instance of Caddy for it and reverse_proxy to it instead.

[michaelbaudino]

Thanks for the answer @mholt, I totally get your point :+1:

And thanks for the idea of running a secondary unprivileged caddy server @pgaskin :raised_hands:

Running as non-root in Docker is actually not as trivial as defining USER in the Dockerfile, since the unprivileged caddy could not persist (autosave) its configuration or access the cache directory.

For the record, I ended up running the whole caddy binary unprivileged (thus on ports > 1024) with Docker being in charge of binding ports 80 and 443. And I had to run a chown -R /data /config in an entrypoint in order allow the unprivileged binary to access those directories.