Mount /nix/store in /tmp/nix/store by default, make nix closures deployable without root

[offlinehacker]

Let's say that you want to have binary deployments on ubuntu system where you don't have root access. What you currently could do is build package with other prefix(your home) with all dependecies, wait a hack of a lot of time to build and finally copy closure in correct location. There's one path on the system that's usually writable by anyone and that's /tmp.

But what if we mount --bind whole /nix/store on /tmp/nix/store and have that as prefix. It would not hurt nix installations in any way, but would allow us to have binary depoyments on non-root systems where you first extract whole closure on /tmp/nix/store and then run application.

I see a huge benefit in this. What do you think?

[shlevy]

-1 from me. /tmp is temporary, from FHS:

Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.

As time goes on and kernels update, this problem can be properly solved by user namespaces. In the mean time, I don't think doing something this semantically incorrect is actually a benefit. I wouldn't oppose work to make nixos be able to work with the store at an arbitrary location (I once made an attempt at that but made a dumb mistake and it was reverted and I didn't try again), after which you could of course do this on your own systems.

[offlinehacker]

Well that's why would i just bind mount /nix/store to /tmp/nix/store, but i
agree that proper solution with user namespaces is needed.

Currently what i do for binary deployment on non-root non nix systems is
build packages for another prefix(/tmp/nix/store) and then wrapper/startup
script extracts that closure on every invocation, but is there any better
solution? I also tried fakechroot, but with no success.
On Jan 27, 2014 2:45 AM, "Shea Levy" [email protected] wrote:

-1 from me. /tmp is temporary, from FHS:

Programs must not assume that any files or directories in /tmp are
preserved between invocations of the program.

As time goes on and kernels update, this problem can be properly solved by
user namespaces. In the mean time, I don't think doing something this
semantically incorrect is actually a benefit. I wouldn't oppose work to
make nixos be able to work with the store at an arbitrary location (I once
made an attempt at that but made a dumb mistake and it was reverted and I
didn't try again), after which you could of course do this on your own
systems.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1605#issuecomment-33337356
.

[vcunat]

Thanks for explaining more clearly / in detail at NixOS/nix#16 (comment). I was being dull a bit, but now I'm fairly sure I understand you. Biggest issues I see:

• Even much greater breaking of FHS and similar standards than now.
• Non-nixos: if /tmp and $HOME (i.e. the temporary and persistent storages of nix store) are on different partitions, then there is a problem. Note that it's by no way uncommon setup. If just symlinking didn't cause issues, it could be OK, but I fear that many programs do things like symlink expansion. Otherwise one has to copy the whole nix store, potentially on every reboot...

Can you elaborate on experiences with fakechroot?

[offlinehacker]

Yes, you would have to copy on every reboot on systems where you don't have
root, but i don't see this as a major problem, it's only solution for
binary deployments.

I will look-up how LD_PRELOAD preforms, but as far as i know you would have
to wrap every binary with LD_PRELOAD hack, because you could allways have a
problem that something ovrrrides LD_PRELOAD.

And patching stuff after it gets build it's even more ugly.
On Feb 6, 2014 12:26 PM, "Vladimír Čunát" [email protected] wrote:

Thanks for explaining more clearly / in detail at NixOS/nix#16 (comment)NixOS/nix#16 (comment).
I was being dull a bit, but now I'm fairly sure I understand you. Biggest
issues I see:

• Even much greater breaking of FHS and similar standards than now.
• Non-nixos: if /tmp and $HOME (i.e. the temporary and persistent
  storages of nix store) are on different partitions, then there is a
  problem. Note that it's by no way uncommon setup. If just symlinking didn't
  cause issues, it could be OK, but I fear that many programs do things like
  symlink expansion. Otherwise one has to copy the whole nix store,
  potentially on every reboot...

Can you elaborate on experiences with fakechroot?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1605#issuecomment-34314314
.

[shlevy]

Closing this, as this doesn't seem to belong in nixpkgs if it's even a good idea at all.