Maybe I'm old, but I remember way too many ENV exposure bugs over the years to be particularly confident dumping sensitive information into the ENV. Admittedly, all software should be sanitizing the ENV for untrusted users, but there's just such a long history of people making mistakes. I'm one of those people, in fact. Sure, frameworks and more modern execution models make it easier to avoid those mistakes today, but I've never accidentally checked in a config file with passwords (except a couple times in my t/ test directory, and that only for test server instances). I've made real data exposing security mistakes with ENV.

>just start a server or an app with different env variables in the command line.

Just reference a different config file on the command line.

>You don't want your config or keys to depend on an OS,or a language.

A path to a config file isn't an OS or language. The ini format is pretty widely supported.

>Finally Env variables can be restricted to a set of users,so third party process started with a different one cant access them.

This is exactly what filesystem permissions do for files already.

    BEGIN {
        $API = new Backend($ENV{credentials});
        delete $ENV{credentials};
    };

Filesystem permissions do not make it possible for a program to internally partition access to those credentials unless you (a) start it as root, or (b) delete the credentials file after reading it.

A user process can start subprocesses under different users, without access permissions to the files owned by parent. The most obvious way to do so is to use sudo.

Using a setuid helper (even if it's called sudo) is still starting a program as root.

Not necessarily; sudo on Fedora has CAP_SETUID instead of the setuid bit, so it doesn't actually run as root.

http://fedoraproject.org/wiki/Features/RemoveSETUID

But CAP_SETUID, unless I'm confusing it with something else, can be used to set the UID to 0 and thereby gain all the same privileges as if the program had been started as root, can't it? Presumably it has some advantage that I'm not getting – does it have to be combined with e.g. SELinux to be useful?

>> just start a server or an app with different env variables in the command line. > Just reference a different config file on the command line.

Either of that seems to be able to be read straight from argv[0] of the process, so don't forget about cleaning that up.

Spring Boot allows all of this at once [1]. You can specify a configuration file in your sources but if you set specific keys in the environment that configuration has a higher priority. I think this is a very good solution.

Particularly this allows you to package a general configuration file, a user can provide an external configuration file and can for a specific instance even overwrite that with env (or command line arguments).

[1] http://docs.spring.io/spring-boot/docs/current/reference/htm...

I agree that ENV variables are useful for general configuration, that's exactly what they were invented for...

ENV variables are not restricted by user though, your process can spawn another process under a different user and give it the same environment. It's the nature of the environment that it is usually inherited from the parent which causes the issues when we're talking about secrets.

Delete sensitive environment variables after you read them, or don't run programs you don't trust with an unsanitary environment/argument list (e.g. execve not system)

Thanks for that idea of deleting sensitive environment variables. I like that for hosters such as heroku which use ENV variables for config (including secrets) by default.