Comment by SwellJoe | Hacker News Reader

Comment by SwellJoe | Hacker News Reader

Parent Full thread

I've always been uncomfortable with the "store config in the environment" part of the 12 factor app thing, since it does imply storing things like database passwords and such, and the argument is that those shouldn't be in files. But, filesystem permissions are reasonably flexible and are easy to reason about (unlike the potential visibility of ENV).

I also don't really buy the arguments for ENV storage of even non-sensitive data. There's just not really any good reason to do so; your config has to be put in place by some tool, even if it is in ENV; why not make your tool produce a file, with reasonable permissions in a well-defined default location? The 12 Factor App article seems to believe that config files live in your source tree, and are thus easily accidentally checked into revision control. That's not where my config files live. My config files live in /etc; or, if I want it to isolate a service to a user, I make a /home/user/etc directory.

One could say, "Don't store passwords in the revision control system alongside your source." And that would be reasonable. But, there's no reason to throw the baby out with the bath water.

> 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)

Reply on news.ycombinator.com