“Move” store to [some long path]

[Ekleog]

So this will likely be a bad idea for retro-compatibility reasons, but here is an idea.

There are currently no good way to run nix as unprivileged user when userns aren't activated and nix isn't installed system-wide. (not really considering proot as a good way, nor re-building everything from source).

An idea may be to have store paths refer to /nix/insert/here/some/very/long/path/just/so/that/we/get/space/for/rewriting/ instead of /nix/store. Then, by patching the binaries, I could just have a store set in /home/my-username-on-shared-system/.nix-store/pad-to-get-to-the-right-number-of-chars/.

In order to not completely break retro-compatibility, all the things written in this long path would also be linked to /nix/store (or this long path could even be a symlink to /nix/store for “normal” setups).

I know path rewriting isn't really reliable yet, but it still sounds like something that should be more or less doable as a hack, and would solve the issue of using home-manager when having to handle computers on which nix couldn't be installed globally.

The thing that prevents doing all that right now is simple: /nix/store is just not long enough, and requires a username of at most 4 characters, even when putting the store directly in the home.

[vcunat]

This idea certainly was discussed at some point (years ago). From the top of my head, there are problems with too long path-names, and I'm afraid this would extend the problems to more users https://github.com/NixOS/nixpkgs/issues/10854

[Ekleog]

Hmm… If the problem is only about the shebang, this means we've got 127 bytes to use. Which, if I'm not mistaken, means around 60 more chars possible to add to the store path (unless using a store path twice in the shebang, but a random pick of store path here was 78-chars long with /bin/ls appended, so that wouldn't pass anyway).

While I say “a very long path”, I actually mean “anything that can be assumed to be long enough to map to a directory controlled by the user. I think assuming usernames are <20 chars (including potential split into /home/[group]/[user] -- the longest I know of is, I think, 14-chars under /home/), which would mean ~28 chars (to allow for a one-letter subdirectory of the home directory at least), while /nix/store currently has 10. So that'd be about 18 chars more.

I wonder whether 18 more bytes in the store path would be enough to trigger breakage that would not already be occurring? Also, I'm thinking maybe having nix force having long paths would avoid this path-length impurity that hit in the issue you linked, NixOS/nixpkgs#10854: this way the packages would be broken for everyone, not only for those with custom stores, and thus nixpkgs would be long-path-to-store-safe.

Obviously, this means the path to there is even more retro-compatibility-ambushed than before, so maybe that'd just be too complex to pull off.

[orivej]

You could try /tmp/smthg.

[7c6f434c]

That was discussed, and the drawback is that /tmp is quite often auto-wiped, and of course there are security problems with re-creating the symlink every time.

[vcunat]

Re-creating a single symlink when starting a user profile seems fairly simple, but I can't claim to know well the intended use case (systems where you can't get write access to /nix nor userns).

[7c6f434c]

Creating a conflict between two user profiles that way sounds simple, too…

(Yes, if there is perfect trust and some coordination between Nix-using users of the machine, the prefixes will be randomized and pre-checked for uniqueness)

[vcunat]

You can rewrite all your paths to another /tmp/random prefix anytime, but yes, that's nontrivial...

[edolstra]

Closing this because there is about zero chance of this ever happening: It would cause a staggering amount of work / migration pain for little benefit (namely, it would only help users who cannot have namespace enabled for some reason).

[vcunat]

BTW, @Ekleog, I'm curious why you dismissed proot. I remember people reported using it successfully years ago, in some restricted environments (scientific clusters or some such IIRC).

[Ekleog]

@vcunat The problem is “years ago”: proot doesn't support recent kernels without lots of quirks https://github.com/proot-me/PRoot/issues/106

@edolstra For users who cannot have userns enabled, well, that's the case of a lot of shared systems where the admin is security-minded :) (not trying to argue, though, as it's indeed a high amount of work for relatively little benefit for the average user)

[vcunat]

Thanks for the link. That's unfortunate.