I have a question about the behaviour of s6-log as it manipulates the
file permissions of .../current.
While configuring a deployment with a narrower umask than usual, I
noticed that .../current would always be world readable despite the
setting of the umask.
Looking at the source code, I notice lines like this:
I understand the motivation to use the permission bits to signal state
> If current has the executable-by-user flag, it means that no s6-log
process is currently writing to it and the
> previous s6-log process managed to cleanly finalize it. If it does
not, either an s6-log process is writing
> to it or the previous one has been interrupted without finalizing it.
I think it is possible to achieve this while also respecting the
What do you think?
Not respecting the configured umask in s6-log deployments could be
regarded as a security risk because it has the potential to expose
sensitive log file content.