s6-setuidgid doesn't change env variables?

[Garreat]

Hello there!

I'm using s6-overlay for quite some time now and I have encountered this issue.
I want to run my daemon as non-root user, so I went like that:

Dockerfile:

(create non-root user)
ENTRYPOINT /init
COMMAND ["/bin/bash", "/script.sh"]

script.sh:

(do some stuff as root)
s6-setuidgid non-root daemon --option1 --option2=x --more --options

My container crashes immediatly, as the daemon tries to create files under /root directory. Looks like s6-setuidgid doesn't set stuff like $USER...?

[services.d] starting services
[services.d] done.
[Errno 13] Permission denied: '/root/...'
Error: failed to write script file in '/root/...

If I skip s6-setuidgid and use traditional su - non-root -c 'long long command', then I don't face this problem.
Is there any advantage using s6-setuidgid over su?
Maybe I should use su as a base for Docker COMMAND?
Feel free to comment!

[glerchundi]

@Garreat there's something I didn't understand, how will a privilege dropped user create a file under the root's home folder?

Anyway, probably @skarnet will answer this much better than me. @skarnet can you explain what was the motivation behind s6-setuidgid? (although this would be something to be asked in the supervision mailing list)

[Garreat]

@glerchundi Obviously there is no way for non-root to create a file there.
Question is, why the command given after s6-setuidgid uses /root as $HOME? One would expect $HOME to be the target user home directory at this point.
For now, I just use su - instead of s6-setuidgid to have the env variables changed for the daemon process.

[skarnet]

s6-setuidgid, as documented, changes the uid and gid of the current process (and optionally the supplementary groups). It's a tool for dropping privileges, not for logging in as a given user.

It's generally a bad idea to run a daemon under a uid you can log in with. For maximum privilege separation, a daemon should have its own uid and there should be no user data (no password, no home directory other than /, no valid login shell) associated with that uid. The fact that you can declare a HOME, or a login shell, in /etc/passwd, is irrelevant and should not be used when declaring uids for your daemons.

@Garreat I strongly suggest changing your daemon so that it does not use the values of the HOME, USER and such variables that are set when logging in. If you need a place to write things in, hardcode a reasonable default (for instance /var/lib/daemonname) and allow it to be changed via a command-line option. Same thing with a config file name (/etc/daemonnamerc). Those values should be totally independent from the uid you're running the daemon as: you don't log in when running the daemon, you just drop your privileges from root to $uid.

[tombburnell]

That seems very idealistic, there may be various things the app might need to do before starting that the app code doesn't have control of - say nvm install as an example. Not being able to cleanly have a shell that reflects the running user is a limitation that will just end up being hacked around by setting the environment manually.

[skarnet]

In that case, you should tailor the service to give the app the exact environment it needs. Profile your apps, see what their requirements are, assess whether those are reasonable requirements or not; if they are, adapt your service.
Giving by default a full user environment to an application is asking for exploits.