This doesn't cause issues typically, but since $HOME is carried over from root it can cause issues like #2317 / #2053 / #1288 that are challenging to diagnose.
It is kind of ugly that we carry over a bogus $HOME value. Since the path is also inaccessible, it's also pointless.
We might consider instead one of the following approaches:
Whitelist instead of preserve the entire environment in run_as?
may cause other side effects (such as breaking non-image variables) since admins pass variables in for other purposes we can't predict/known ahead of time
Set HOME to the correct value
prepending HOME=/var/www to the su call
easy, targeted fix
This PR takes the second approach.
This should cut down on problems people encounter when running up against third-party tools that query $HOME. Since the value was already problematic, I can't think of any problems this will cause. It should not be a breaking change.
Fixes #2317 Fixes #2053 Fixes #1288
We preserve the environment - because we need it - when executing commands:
https://github.com/nextcloud/docker/blob/d03da64ac80d534c1b0ec69da3e6ddcc6af282a6/30/apache/entrypoint.sh#L14-L20
This doesn't cause issues typically, but since
$HOMEis carried over fromrootit can cause issues like #2317 / #2053 / #1288 that are challenging to diagnose.It is kind of ugly that we carry over a bogus
$HOMEvalue. Since the path is also inaccessible, it's also pointless.We might consider instead one of the following approaches:
run_as?-p, switching to-lwith a whitelist (-w): https://man.archlinux.org/man/su.1.en#OPTIONSHOMEto the correct valueHOME=/var/wwwto thesucallThis PR takes the second approach.
This should cut down on problems people encounter when running up against third-party tools that query
$HOME. Since the value was already problematic, I can't think of any problems this will cause. It should not be a breaking change.