logging: Allow setting log file permissions

[ririsoft]

Adding a "mode" option to overwrite the default logfile permissions.
Default remains "0600" which is the one currently used by lumberjack.

Fixes #6295

I am assuming that Mode = 0 triggers usage of default mode "0600". That implies that users cannot use a "0000" mode for their log files. This sounds reasonable to me, but your opinion here would be appreciated.

I did not test the PR in production. I only tested in local and all went fine. Beware that your umask may interfere with the mode from the config: this is why umask is unset in the tests.

This is my first PR here. I would appreciate great care in the code review, I am fully open to your comments of course.

Cheers.

[CLAassistant]

All committers have signed the CLA.

[mohammed90]

The os.FileMode type is an alias to fs.FileMode, which is defined as uint32. The mode 777, for example, is ought interpreted as octal by those parsing the string (pun-intended) of characters in the context of file mode. However, the initial (un)marshaling of the value in Go treats it as decimal. Going back to the example of 777, the user is expected to pass the integer 511 (the equivalent of o777) to get the effect of o777, which is confusing.

I'm torn between simply using a string versus defining a new type, e.g. type FileMode string with custom UnmarshalJSON method (like caddy.Duration) that can accept integers (assuming the digits are octal) as well as strings to be interpreted in the form rwxrwxrwx, but the latter may be an overkill.

I know you're not a Go dev. Sorry for making this more complicated/work for you 🙂

[mholt]

Hmm, that's an interesting idea. I'd be willing to contribute that custom unmarshaler but need some time before I can get around to it.

[ririsoft]

What about reproducing the behavior of the unix chmod command ?

A numeric mode is from one to four octal digits (0-7), derived by adding up the bits with values 4, 2, and 1. Omitted digits are assumed to be leading zeros.

The following would be equivalent for instance:

file access.log {
  mode 777
}

file access.log {
  mode 0777
}

That way we keep users in the same confort zone they are with chmod and filesystem permissions.
What do you think ?

[francislavoie]

Remember, that's only the Caddyfile config. You need to also consider JSON config. The Caddyfile adapter produces a JSON config, but it should also be erogonomic for JSON config users to configure this. The type of the field itself dictates how its configured via JSON.

[ririsoft]

I know you're not a Go dev. Sorry for making this more complicated/work for you 🙂

I used to code in Go a few years ago, I am having fun rediscovering it, no worry.

I'm torn between simply using a string versus defining a new type, e.g. type FileMode string with custom UnmarshalJSON method (like caddy.Duration) that can accept integers (assuming the digits are octal)

Considering that leading zeros are invalid json number it seems that if we want to allow users to use octal number with a leading zero we have no choice to use a json string I guess ? Tell me what you think and I will submit a new commit with an implementation proposal, and squash all the work once you are all ok with the PR.

as well as strings to be interpreted in the form rwxrwxrwx, but the latter may be an overkill.

Would you still accept my pull request if I let this one for somebody else's implementation ? Definitely overkill to me :D

[mholt]

@ririsoft That's what @mohammed90 was referring to: if we make our own type, we can decode a chmod-style string as an octal number.

[ririsoft]

Thanks @mholt, I will submit a new commit with such proposal in a few days then.

[francislavoie]

Alternatively (or in addition) to this, we could allow specifying the permissions like #4741 as in /path/to/file.txt|0666

[francislavoie]

Tests are failing on Windows - I think what you'll need to do is only do this test on non-Windows (same way, with //go:build !windows).

[ririsoft]

Ok so now errors are more clear to me. Let me try a few things to have some minimal testing on windows too.

[mholt]

Nice work cranking through this! :) I'll circle back after the 2.8 release.

[ririsoft]

I have a race condition in the tests with the generation of compressed log file. I will fix that so that you can review the PR with CI OK.

[mholt]

Thank you for this! Looks pretty good, I just had a couple questions/suggestions for consideration. Will likely merge soon!

[mholt]

Gotcha. Thanks for the careful consideration and the tests!

Looks good. Let's give it a whirl. Thank you for the contribution!!

[ririsoft]

Gotcha. Thanks for the careful consideration and the tests!

Looks good. Let's give it a whirl. Thank you for the contribution!!

Thank you @mholt , @francislavoie , @mohammed90 for your help with this PR. Allow me to congratulate you all, and @mholt in particular, for the amazing work you are doing with Caddy as well as the way you lead the project for contributions in the open. It was really easy to on-board and hack. Well done !

[bhavin-qryptal]

Dear Team,

I am using caddy version v2.8.4 and I am trying to have read access granted to caddy log file to all users. Based on this pull request, I have got Caddyfile with section like ...

log { output file /var/log/caddy/access.log { mode 644 } }
This is not working, could someone please guide me in correct direction. I am newbie with caddy / golang.

[francislavoie]

In what way is it not working? Show evidence.

[mholt]

Also probably open a new issue with enough information to reproduce the bug 👍

[bhavin-qryptal]

In what way is it not working? Show evidence.

Thank you for prompt reply.

access.log file permission remains 600, I am expecting it to be 644. Please let me know if you need any other details.

[bhavin-qryptal]

Also probably open a new issue with enough information to reproduce the bug 👍

At this stage, I am not sure, whether this is a bug OR I am doing something wrong. Is the change discussed in this thread included in v2.8.4 ?

[francislavoie]

Ah, it's not been released, no. It was merged June 6th, last release was June 2nd. You can build from master if you want it now.

[bhavin-qryptal]

log { output file /var/log/caddy/access.log { mode 644 } }

Thanks a lot. I will give it a go.

Hope this looks reasonable to you.

[jjlin]

After updating to Caddy 2.9.0, I immediately ran into the issue of my log files being inaccessible. For backward compatibility, I think it would've been better to use the previous default of 644 even if Lumberjack changed the default on their side, but if you don't want to do that, it would be nice to explicitly call this out as a breaking change (sorry in advance if it's actually mentioned somewhere and I missed it).