I've had certbot running for a year or so to renew a wildcard certificate for my domain using dns-01 challenge. After renewal the certificate is deployed to some web servers, all of which are internal (not exposed to the internet). It all works just fine but I'm in the process of switching to a different platform. I don't want to install snap and the new platform is running Turnkey Linux which has the dehydrated ACME client pre-installed, so I thought I'd give that a try.
I've got it working but while doing some background reading I came acrosss some discussions about permissions. One or two people mentioned that they use their own wrapper that launches dehydrated with restricted permissions (us about best practicesing "sudo -u nobody") so that only the wrapper needs root permissions. That sounds like an interesting idea but I'm baffled about how the 'nobody' user would be able to create the various files.
In my case everything is behind my firewall it's not really much of a concern to run as root anyway but it got me wondering. I'd be interested to know what people consider "best practices" for this sort of thing.
My domain is:boxersoft.com
I ran this command:N/A
It produced this output:N/A
My web server is (include version):various
The operating system my web server runs on is (include version):Various Linux and Linux-like.
My hosting provider, if applicable, is:N/A
I can login to a root shell on my machine (yes or no, or I don't know):Yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):Dehydrated version: 0.7.0
I'd say just run it as root, just as Certbot is run as root. Dehydrated is just bash and while it's 2400 lines long, it wouldn't be too difficult to scan the (single) file for strange behaviour you'd not want running as root.
Note that my opinion is not a "best pratices" and I don't think such a thing actually exists.
As far as I know the nobody user is still a user, it's just that by default they have no special permissions or ownership (with no home etc). You can still allow the nobody user write access. It strikes me as a defacto-standard and perhaps slightly lazy alternative to creating a dedicated user for the job (which would have the same effect but be more clearly intentional)?
Hmmm... I thought I had read that the nobody user was a special case. I had tried switching to nobody and failed to perform some write operations but trying again just now it worked, so I guess I must have done something wrong previously. I also found the following in the Ubuntu wiki, strongly discouraging the use of nobody. I guess I won't be doing that then
Some misguided programs or guides suggest that this user should be used for untrusted program execution or handling untrusted data. This is bad advice. Services should have their own, dedicated, user account. Even on sites where NFS is not being used, processes run as user nobody or files owned by user nobody may grant far more privileges than expected, especially if two services have been misconfigured in this fashion.
Do not use the user nobody for anything. It is for NFS.
Every Linux distribution treats the default users like "nobody" differently. That advice holds true to Ubuntu, but may not work on others.
One of the more classic ways to do this is by "shedding permissions" and using groups. A process would start with root permissions to bind to ports and access certain files. Then it drops to another, less privileged, user who has Group permissions to read/write in a directory. A lot of web servers act like this - the main process binds to the port with full access to files, but all the spawned workers who actually respond to requests are run as a less privileged user.
Noted, thanks. I had read that web servers and some other processes start as root then drop to a lower privilege level but I hadn't come across the term "shedding permissions". Could be a useful search term for further reading.
