[Ericson2314]

If I had my way

1. store paths would have no names at all

2. listing the contents of the store directory would not be allowed

3. store paths have more bits of information

Then store paths are halfway decent (but non-revocable) capabilities.

[eviks]

> 2. listing the contents of the store directory would not be allowed

Wow, that's awful, that's what Windows AppStore does, so it's even hard to see how much of the preinstalled garbage there is or even whether you might have a huge game you forgot to uninstall but might want to to free up some space.

What's the cool benefit that could justify this limitation?

[tadfisher]

Nothing should rely on how store paths are named, ever. Like, there is actually no reason to know that hash 1234abc is a certain output of derivation xyz-12.1.0. The contents of the store can be garbage-collected at any point. So you actively do not want things outside the Nix store (or managed by NixOS tools, or Nix-aware tools) referencing paths in /nix/store.

If you do something like write a config file that references /nix/store/1234abc-xyz-12.1.0/bin/xyz, that config file will break the next time you update the derivation that produces that path. Again, this makes knowing what things are in the store completely pointless unless you are writing Nix-aware tooling or debugging, in which case there are tools to show you what path your derivation produced. But you should never need to do the opposite, which is to resolve which derivation produced a path in /nix/store/.

The Windows Store problem is completely orthogonal; paths in /nix/store are not "installed" on your system, they are derivations or outputs of Nix derivations. NixOS "installs" things by adding some of these to your PATH in a shell script that is also a derivation output in /nix/store.

[Ericson2314]

Very well said, thank you!

I'm glad other people also understand that the onus of motivation is on granting some privilege, not rescinding it :)

[gf000]

I'm afraid this doesn't work in a generic Unix world -- what stops an application from saving some env variable it was first initialized with into its local config and later accessing them (and potentially failing if they were GCd in the meanwhile)? E.g. many developer tools store references to compilers and the like.

[Ericson2314]

Nix is over 20 years old. We've fought all those tools and won by now. (I.e. we've figured out how to configure them to not do that when we don't want them too.)

[gf000]

I am using Nix everywhere and have some packages contributed, so I do know how it goes - and there absolutely are cases like I have mentioned. Sure, apps can be patched, problems can be circumvented, but a fundamentally malicious/ignorant program can end up a pain in the ass for nix to manage (without bringing out the big guns like build FHS env)

[tracnar]

What actually happens if you remove read permissions on the /nix/store directory? Do things still work? I suppose I'll need to try!

[kevincox]

https://github.com/NixOS/rfcs/blob/master/rfcs/0097-no-read-... is relevant.

[Ericson2314]

Oh hmm did we never implement this? We should. Both because it is a good idea, and because accepted RFCs should be implemented.

[kevincox]

I'm not aware of it being done yet. But since the RFC is accepted it should be pretty straightforward.

[vatsachakrvthy]

How could one debug if we couldn't view contents of the store directory?

[Ericson2314]

You can still read individual store objects in their entirety. You just need to know the store path for the object that you want to read.

You can still use root or something to list all the store paths. (But ideally nothing else would be running as root / with that power.)