> filesystem permissions are reasonably flexible

Env makes things really flexible.For instance,you can call a program with env variables directly thus overriding the default ones,which simplify configuring applications. You dont have to have a test set-up,a production-setup or a staging set-up,just start a server or an app with different env variables in the command line.

You don't want your config or keys to depend on an OS,or a language. Finally Env variables can be restricted to a set of users,so third party process started with a different one cant access them.

I believe env variables are better than other solutions.

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.

Config is ultra-sensitive information. It's like not having the right .gitignore if you're backing up /etc in git or not having enough password log filters.

The issue is that ultimately, one has to trust some infrastructure as being of an ultimately trusted network (whether it's Puppet/Chef/cfe2+ or offline authoritative CA's)