[bacheson1293]

Absolutely. This situation is handled by using Environment variables. Depending on the environment, I use environment variables to point services at different places (ie dedicated production database server vs my micro dev mysql container).

[falcolas]

Remember that environment variables are visible to processes outside the container (i.e. users), if they have the same or higher privileged user. They are not a great place to store passwords or any other confidential information.

[justincormack]

The environment of a process is only available to root or the same uid.

[falcolas]

    vagrant@monitor:/proc$ sudo -u nginx cat 1779/environ

UPSTART_INSTANCE=runlevel=2UPSTART_JOB=rcTERM=linuxPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/binRUNLEVEL=2PREVLEVEL=NUPSTART_EVENTS=runlevelPWD=/previous=N

It's not uncommon to allow users to sudo up to particular system users for commands, nor it is uncommon for compromised programs to give the attacker a shell as the user of the compromised program.

Anything owned by that user is vulnerable. A common problem which is typically resolved by reading a config file while root and downgrading to a lower privilege user. For example, you wouldn't want anyone who could become the nginx user to get the SSL key, or the password to your S3 bucket, or...

[justincormack]

You do not give the nginx user sudo ability, and any user who has sudo is root, and should be treated as such.