сс @infinisil cc @Mic92

Returned AmbientCapabilities = [ "CAP_NET_BIND_SERVICE" "CAP_SYS_RESOURCE" ];

@Izorkin: Does nginx still have permission to access letsencrypt certificates if we use services.nginx.virtualHosts.<name>.enableACME?

I didn't check yet, just asking.

Also, it seems the ACME test currently is broken on master so I can't easily check it in the test

cc @NinjaTrappeur @arianvp

@flokli yes, correct work:
ls -lah /var/lib/acme

итого 16K
drwxr-xr-x  4 root  root  4,0K дек 17 20:07 .
drwxr-xr-x 26 root  root  4,0K дек 17 20:10 ..
drwxr-xr-x  3 root  root  4,0K дек 17 20:07 acme-challenge
drwxr-xr-x  2 nginx nginx 4,0K дек 17 20:07 test1.example-stie

ls -lah /var/lib/acme/test1.example-stie

итого 32K
drwxr-xr-x 2 nginx nginx 4,0K дек 17 20:07 .
drwxr-xr-x 4 root  root  4,0K дек 17 20:07 ..
-rw-r--r-- 1 nginx nginx 3,1K дек 17 20:07 account_key.json
-rw-r--r-- 1 nginx nginx  912 дек 17 20:07 account_reg.json
-rwx------ 1 nginx nginx 3,9K дек 17 20:07 fullchain.pem
-rwx------ 1 nginx nginx 7,1K дек 17 20:07 full.pem
-rwx------ 1 nginx nginx 3,2K дек 17 20:07 key.pem

Acme tests still pass after merging this in, so should be good to go. Thanks!

@tbenst mentioned this broke nginx, as it's not able to open the log file:

Dec 22 03:54:01 hydra-server jdf8k5jc38ny3zfshcnxxiw52l9h8x4b-unit-script-nginx-pre-start[18157]: 2019/12/22 03:54:01 [emerg] 18158#18158: open() "/var/spool/nginx/logs/access.log" failed (13:>

When checking on a NixOS 19.09 machine however, I couldn't reproduce log files being owned by root. @NinjaTrappeur , @asymmetric, any thoughts?

Before update -

sudo ls -lah /var/spool/nginx/logs
итого 20K
drwxr-x--- 2 nginx nginx 4,0K дек 22 15:53 .
drwxr-x--- 8 nginx nginx 4,0K дек 22 15:53 ..
-rw-r--r-- 1 root  root  1,4K дек 22 15:53 access.log
-rw-r--r-- 1 root  root   134 дек 22 15:53 error.log
-rw-r--r-- 1 root  root     5 дек 22 15:53 nginx.pid

After this PR -

итого 16K
drwxr-x--- 2 nginx nginx 4,0K дек 22 18:08 .
drwxr-x--- 8 nginx nginx 4,0K дек 22 18:08 ..
-rw-r--r-- 1 nginx nginx 1,4K дек 22 18:08 access.log
-rw-r--r-- 1 nginx nginx  132 дек 22 18:08 error.log

Need remove log files or change owner to nginx

This should do the trick:

systemd.tmpfiles.rules = [
  "Z '${cfg.stateDir}/logs' 0750 ${cfg.user} ${cfg.group} - -"
];

This commit breaks services.nginx.virtualHosts.<vhost>.useACMEHost, even with security.acme.certs.<vhost>.allowKeysForGroup and group nginx. I haven't figured out why, yet.

It's because the permissions on the pem files that acme writes are -rwx------ and ownership is root:nginx

edit: I believe this is because I didn't originally have allowKeysForGroup set. It was working anyway because nginx was reading certs as root. Now that it's not, I noticed that allowKeysForGroup was not set. I've enabled it, but it appears that the acme service only sets permissions to 0750 if allowKeysForGroup is set when it renews certs, which mine hasn't done.

tldr; I think this is a configuration issue on my end and it shouldn't affect other users who've set it up properly. I'll confirm later when I've had a chance to check this.

edit2: yes, it's as I explained. This was just a configuration error on my end that manifested once the change to the nginx module was made. Sorry for the false alarm.

I have the suspicion that this file broke running nginx as root:

When you manually configure services.nginx.user = "root";, file uploads fail like this:

Apr 02 18:24:33 myhostname nginx[11878]: 2020/04/02 18:24:33 [crit] 11885#11885: *71 open() "/var/spool/nginx/client_body_temp/0000000012" failed (13: Permission denied)

Here, the nginx master process 11878 runs as root (as configured) and the worker process 11885 runs as nobody.

The directory permissions are:

# ls -lah /var/spool/nginx/
total 32K
drwxr-x--- 8 root   root 4.0K Apr  2 18:59 .
drwxr-xr-x 3 root   root 4.0K Apr  2 18:04 ..
drwx------ 2 nobody root 4.0K Apr  2 18:22 client_body_temp
drwx------ 2 nobody root 4.0K Apr  2 18:22 fastcgi_temp
drwxr-x--- 2 root   root 4.0K Apr  2 18:22 logs
drwx------ 2 nobody root 4.0K Apr  2 18:22 proxy_temp
drwx------ 2 nobody root 4.0K Apr  2 18:22 scgi_temp
drwx------ 2 nobody root 4.0K Apr  2 18:22 uwsgi_temp

Because /var/spool/nginx/ is rwxr-x--- (lacks x for non-root user/group), the nobody user cannot traverse and thus write into the subdirectory it owns (client_body_temp).

In other words, it seems like the lines

2a413da#diff-795fa65a7c41a479084de826e4e2e65cR672

    systemd.tmpfiles.rules = [
      "d '${cfg.stateDir}' 0750 ${cfg.user} ${cfg.group} - -"

do not have the desired effect: Yes, they change the parent directory, but if nginx then drops privileges as it did before, child dirs cannot be written to with the dropped perms.

@nh2 which also implied, nginx won't be able to write to logs directory, as it is not nobody writeable...

Looks like root requires exceptional handling here.

I'm having an issue very similar to this, but with services.ngnix.user set to the default. The issue is that the nginx user cannot write to client_body_temp or proxy_temp (or any of the other directories with group of nobody. This causes issues for Airsonic (when I download files) and Marix (when I send messages) because Nginx aggressively buffers large downloads and uploads using files in client_body_temp and proxy_temp.

My workaround for now has been to just SSH to my server and chown -R nginx:nginx /var/spool/nginx, but this is not sustainable. Should the Nginx module also have rules for:

      "d '${cfg.stateDir}/client_body_temp' 0750 ${cfg.user} ${cfg.group} - -"
      "d '${cfg.stateDir}/fastcgi_temp' 0750 ${cfg.user} ${cfg.group} - -"
      "d '${cfg.stateDir}/proxy_temp' 0750 ${cfg.user} ${cfg.group} - -"
      "d '${cfg.stateDir}/scgi_temp' 0750 ${cfg.user} ${cfg.group} - -"
      "d '${cfg.stateDir}/uwsgi_temp' 0750 ${cfg.user} ${cfg.group} - -"

(which are the directories that nginx appears to create) in addition to the already existing:

      "d '${cfg.stateDir}/logs' 0750 ${cfg.user} ${cfg.group} - -"

?

I'm very new to this whole NixOS thing, so maybe there's a better way of achieving what I'm trying to accomplish.

@nh2 @sumnerevans since 50d6e93, there should be a Z line in tmpfiles that should chown /var/spool/nginx recursively to cfg.user / cfg.group - shouldn't nginx be able to create and update files in there with that?

@flokli I suspect that should help with @sumnerevans issue, but it seems that it wouldn't help with mine, since as described above, nobody is relevant for that.

I misspoke in my last comment. The user is nobody, the group was nginx (totally forgot which way ls output worked 🤦‍♂️

Sorry, I'm now confused. Specifying root as a user likely requires special handling. Could both of you open issues with example configurations?

Specifying root as a user likely requires special handling.

That is what was there before:

• Before, the systemd service ran as root, so the nginx master process ran as root, and then the worker processes ran as an unprivileged user (user nginx nginx here, or nobody by default if thta line is not given).
• Now the systemd service runs as nginx, including the master process.

Could both of you open issues with example configurations?

Yes. Done in #84391.