Repository navigation
Support private files in the Nix store #8
Description
Sometimes it's desirable to have files in the Nix store that are not world-readable, such as configuration files containing passwords. This could be implemented as follows:
- Private files are marked as such by giving them a certain magic prefix to the name, e.g.
p:. When these are registered, Nix should make them readable only to root (permission 0700) and the calling user (using an ACL). (The Nix daemon knows the uid of the caller.) - The permissions on a derivation should be propagated to the output paths. Also, private derivations should be run with a umask of 0077.
- If another user attempts to register an already valid private file, then its uid should be added to the ACL of the file. If it's a derivation, then the uid should also be added to the ACLs of any valid outputs.
- Store operations that read files from the store (such as
exportPath()) should check that the caller is in the ACL of the file.
So, for instance, if the root user builds a NixOS configuration containing some private files, then those files are only readable as root. If Alice builds the same configuration, then those files will be readable by root and Alice. If Alice then uses Charon to copy the configuration to a remote machine (i.e. nix-copy-closure --to root@remote ...), then the files on the remote machine will only be readable by root.
This model only allows files that are private to the instantiating user and root. So it doesn't support specifying a file that is readable only to the sshd user. But that's probably not necessary.
Activity
shlevy commentedon May 10, 2012
A few questions:
nixos-rebuild buildas non-root?edolstra commentedon May 16, 2012
viric commentedon May 31, 2012
What about the build users? Should they be in the ACLs?
chaoflow commentedon Jul 26, 2012
Being able to tell that somebody else generated the same private file sounds like a no-go for me.
What do you think about including the user the file is private to, i.e. the one who created it, to be included in the hashing (for example an empty file with the user's name in the output)? So even if root, Alice and Charon all want a file with the same content, they would end up with 3 different files.
shlevy commentedon Jul 26, 2012
The problem with including the user in the hashing is you may eventually share stores, but it's better than nothing. Maybe a wrapper function in nixpkgs that hashed in a GUID read from some personal file? So I have ~/.nixpkgs/guid and when I run pkgs.lib.privateFile 'mypass' "passw0rd" it creates a file whose first line is passw0rd and the second line is the guid?
edolstra commentedon Jul 26, 2012
Why is this a problem? If the secret stored in the file is sufficiently secure (i.e. random), then this won't happen. I mean, if your login password is "foobar", then other people may be able to find out. So just don't do that.
shlevy commentedon Jul 26, 2012
Eh, it's not really a problem, at least not for nix itself. The security-paranoid folk can just make sure all of their private files have some unique identifier included.
mornfall commentedon Mar 31, 2013
Unless I am mistaken, private files in the store are sensitive to offline dictionary attacks, since you can learn the hash and you have a procedure to check your guesses. It is also conceivable, that a rainbow attack could be mounted against a particular version of nixpkgs. It would be advisable that any such private files contain significant salting, regardless of the "learn a secret by random collision" problem. A hypothetical lib.privateFile could then enforce that salting by taking a template string and substituting in the salt (which makes it possible to hide that salt in comments or other such convenient places).
viric commentedon Mar 31, 2013
Yes, the sysadmin could care storing the salt somewhere only readable by the root user.
domenkozar commentedon May 27, 2013
There is a use case for
pkgs.baculathatbaculauser needs access to a configuration file with passwords (so non-root).MarcWeber commentedon Nov 30, 2013
Alternative quick & dirty solution which may be useful for some use cases: https://github.com/MarcWeber/nix/blob/experimental/write-file-hashed/.topmsg
domenkozar commentedon Feb 22, 2014
Better link to see @MarcWeber diff: https://github.com/MarcWeber/nix/compare/experimental;write-file-hashed
What's the current workaround for this if a config file includes a password?
MarcWeber commentedon Feb 23, 2014
My version allows storing passwords in config, but instead of writing it to the store a path to a file containing it will be written to the store. The containing file can be read only by root. The complicated piece is that you have to write code which has to be run as root (eg when preparing config files for services) - but its very easy to review (eg in contrast to patching nix store allowing paths to be readable by some users only requires to think about many issues such as copying store paths - preserving privileges thereby etc). State is "I don't use my patch but it should be working".
103 remaining items
libutil: trace unwinding through async tasks
test+doc(eval-trace): §3b follow-up NixOS#8 — RETRACT NixOS#7; flatte…
doc(eval-trace): thread NixOS#8 retraction through RFC §8 cross-refer…
doc(eval-trace): draft derivation-producer-partition RFC + adversaria…
doc(eval-trace): partition RFC adversarial pass NixOS#8 (fresh-eyes) …
Make LocalStore::optimisePath_() non-recursive
v3 Track E W2a: frame-Env root-walking GC scaffold (RootVisitor::visi…
v3 BEAT_TW_V3_PLAN handback: W2a adversarial review NOT REFUTED (root…
v3 W2b-runtime scaffold: Closure::capturedDefEnv field + GC-walk (no-op)
docs(eval-cache): add forcedness-independence as foundational principle
test(eval-cache): lock in principle NixOS#8 — cb arg forcedness indep…
feat(eval-cache): drop K from apply-result CDI computation — content-…
feat(eval-cache): per-invocation walk for apply-result CDI evolution
tomberek commentedon Aug 13, 2026
Closing as stale. Re-open if needed.