Quite simple, Caddy now always tries to chmod log files, even if the new mode option was not set (because it effectively defaults to 0600 regardless), and curiously even if the file’s mode is already matching that.
The error message is like this:
Error: loading initial config: loading new config: setting up custom log 'log0': opening log writer using &logging.FileWriter{Filename:"/var/log/caddy/try-and-write-this", Mode:0x0, Roll:(*bool)(nil), RollSizeMB:0, RollCompress:(*bool)(nil), RollLocalTime:false, RollKeep:0, RollKeepDays:0}: chmod /var/log/caddy/try-and-write-this: operation not permitted
In this case, I made /var/log/caddy/try-and-write-this be owned by root, but gave the user Caddy runs as write permissions through ACLs.
sudo mkdir -p /var/log/caddy &&
sudo touch /var/log/caddy/try-and-write-this &&
sudo chown -R 0:0 /var/log/caddy &&
sudo chmod 0600 /var/log/caddy/try-and-write-this
On macOS then do:
sudo chmod +a 'user:caddy allow read,write' /var/log/caddy/try-and-write-this
Or the Linux way:
sudo setfacl -m u:caddy:rw /var/log/caddy/try-and-write-this
Really just make Caddy unable to chmod the file. It used to not care at all about it in previous versions, now it results in an immediate failure. But obviously not a big deal. You just make sure the log files are actually owned by the Caddy user, so that it is allowed to do a chmod on them, and don’t rely on ACLs. Still it’s a bit weird it insists on attempting the chmod even when the file is already the desired 0600.
In my real world situation I obviously wasn’t trying to intentionally screw over Caddy, only while I was building my configuration, I would often sometimes switch between running Caddy as its final intended and separate user as a background daemon, and sometimes in the foreground tweaking the configuration running under my regular user account, so I didn’t have to authenticate all the time. And simply used ACLs to give the necessary rights to either user.