3 ms·

> The configuration / state for a program is scattered between /etc /nix/store ~ ~/.config /var That's not really scattered. /nix/store has the generated files

> The configuration / state for a program is scattered between /etc /nix/store ~ ~/.config /var That's not really scattered. /nix/store has the generated files. They get linked to /etc if the app requires that kind of thing - often it's just added to the arguments instead. ~/.config is for user preferences (possible to flip at app runtime or static) which are not a system setting. /var is for system services states. Those are very separate use cases and get managed in different ways. The apps should also never be aware that /nix/store is a thing.

charcircuit 3y ago
>Those are very separate use cases and get managed in different ways. To me they all look the same. For example you could have a /nix/state that had a directory for each program. Each program could have its own global and user specific state it could manage from within its directory.
- viraptor 3y ago
  What would be the benefits of merging those?
  - charcircuit 3y ago
    It's simpler and would allow you to do sandboxing by not exposing your entire filesystem to a program.
    - viraptor 3y ago
      This is already done in nixos for daemons: https://github.com/NixOS/nixpkgs/blob/65a62c9f75dc97714f836cae40656c254261f7a3/nixos/modules/services/backup/snapraid.nix#L176 https://github.com/NixOS/nixpkgs/blob/65a62c9f75dc97714f836c... and that's on top of the usual stuff systemd exposes. Then you get firejail for more custom apps. You still need that layer and needs to be configured per-app. Would moving config+state into one path really improve the experience? In what way would it be simpler?
- someplaceguy 3y ago
  > For example you could have a /nix/state that had a directory for each program. NixOS already has that. It's called `/var/lib`. > Each program could have its own global and user specific state it could manage from within its directory. The user-specific state is (and should be) in each user's home directory, not scattered around in a bunch of system-wide directories, one for each application... That's not just for convenience, but also for security (and privacy) reasons. I'd be interested to know who gets to manage the user-specific state in your proposal. Does each app have it's own per-user directory for each user? i.e. if you have 1000 apps and 10 users, do you need exactly 10,000 user-specific directories? And if not, who gets to create these directories and when are they created/removed? To be honest, it sounds like you're not aware of all the complexities and implications / consequences of what you're proposing, i.e. it sounds like you didn't think this through. But on the off-chance I'm wrong, I'd be happy to be proven so.
  - charcircuit 3y ago
    >The user-specific state is (and should be) in each user's home directory, not scattered around in a bunch of system-wide directories, one for each application... I disagree with this because state is owned by the program so it would make the most sense for it to live in the directory for the program. A user can tell the program that they want to modify the state, but ultimately the program has total ownership of its state. The program should not be leaching into user's home directory to read and write files and should be restricted to directories it owns. >I'd be interested to know who gets to manage the user-specific state in your proposal. One way to do it would be for the program to manage it. >Does each app have it's own per-user directory for each user? It could choose. >if you have 1000 apps and 10 users, do you need exactly 10,000 user-specific directories? This is unrealistic. On the want majority of computers an app will only be run by 1 user. Focusing on handling multiple users is a more special case and is a distraction from the point I'm trying to make.
    - someplaceguy 3y ago
      > One way to do it would be for the program to manage it. Really? So a program can access (and modify!) the state of all of its users? Do you realize how easy it would be to trick my Firefox instance into reading (and even modifying) the state of another user, and even running other code on behalf of another user, given that it would have privileges to do so? If I understand correctly your proposal, you basically just converted almost every single application bug into a privilege escalation bug. Not to mention that how do you even define what the same "app" is? Is Firefox 28 the same app as Firefox 45? And if so, can a user install his own Firefox (like you currently can on NixOS and even other OSes)? Also, how would you backup all of your own per-user state, given that every app can decide to manage it differently (i.e. storing it in different files and/or directories inside their own per-app directory, or perhaps even in a single per-app database which you wouldn't have access to). Look, I'm not trying to grill you, I just think you haven't thought this through (but again, I'm happy to be proven wrong). > This is unrealistic. On the want majority of computers an app will only be run by 1 user. Focusing on handling multiple users is a more special case and is a distraction from the point I'm trying to make. What does this even mean? We're talking about user-specific state. So there's different state for each user, which means there are multiple users, by definition! So how is focusing on multiple users a distraction? It's the whole point... As I mentioned, on NixOS, the system-wide mutable state is already stored on /var/lib/<app>, which is what you are (redundantly) proposing. So we're just arguing about how to handle user-specific state, nothing else.

charcircuit 3y ago

>Those are very separate use cases and get managed in different ways. To me they all look the same. For example you could have a /nix/state that had a directory for each program. Each program could have its own global and user specific state it could manage from within its directory.

viraptor 3y ago
What would be the benefits of merging those?
- charcircuit 3y ago
  It's simpler and would allow you to do sandboxing by not exposing your entire filesystem to a program.
  - viraptor 3y ago
    This is already done in nixos for daemons: https://github.com/NixOS/nixpkgs/blob/65a62c9f75dc97714f836cae40656c254261f7a3/nixos/modules/services/backup/snapraid.nix#L176 https://github.com/NixOS/nixpkgs/blob/65a62c9f75dc97714f836c... and that's on top of the usual stuff systemd exposes. Then you get firejail for more custom apps. You still need that layer and needs to be configured per-app. Would moving config+state into one path really improve the experience? In what way would it be simpler?
someplaceguy 3y ago
> For example you could have a /nix/state that had a directory for each program. NixOS already has that. It's called `/var/lib`. > Each program could have its own global and user specific state it could manage from within its directory. The user-specific state is (and should be) in each user's home directory, not scattered around in a bunch of system-wide directories, one for each application... That's not just for convenience, but also for security (and privacy) reasons. I'd be interested to know who gets to manage the user-specific state in your proposal. Does each app have it's own per-user directory for each user? i.e. if you have 1000 apps and 10 users, do you need exactly 10,000 user-specific directories? And if not, who gets to create these directories and when are they created/removed? To be honest, it sounds like you're not aware of all the complexities and implications / consequences of what you're proposing, i.e. it sounds like you didn't think this through. But on the off-chance I'm wrong, I'd be happy to be proven so.
- charcircuit 3y ago
  >The user-specific state is (and should be) in each user's home directory, not scattered around in a bunch of system-wide directories, one for each application... I disagree with this because state is owned by the program so it would make the most sense for it to live in the directory for the program. A user can tell the program that they want to modify the state, but ultimately the program has total ownership of its state. The program should not be leaching into user's home directory to read and write files and should be restricted to directories it owns. >I'd be interested to know who gets to manage the user-specific state in your proposal. One way to do it would be for the program to manage it. >Does each app have it's own per-user directory for each user? It could choose. >if you have 1000 apps and 10 users, do you need exactly 10,000 user-specific directories? This is unrealistic. On the want majority of computers an app will only be run by 1 user. Focusing on handling multiple users is a more special case and is a distraction from the point I'm trying to make.
  - someplaceguy 3y ago
    > One way to do it would be for the program to manage it. Really? So a program can access (and modify!) the state of all of its users? Do you realize how easy it would be to trick my Firefox instance into reading (and even modifying) the state of another user, and even running other code on behalf of another user, given that it would have privileges to do so? If I understand correctly your proposal, you basically just converted almost every single application bug into a privilege escalation bug. Not to mention that how do you even define what the same "app" is? Is Firefox 28 the same app as Firefox 45? And if so, can a user install his own Firefox (like you currently can on NixOS and even other OSes)? Also, how would you backup all of your own per-user state, given that every app can decide to manage it differently (i.e. storing it in different files and/or directories inside their own per-app directory, or perhaps even in a single per-app database which you wouldn't have access to). Look, I'm not trying to grill you, I just think you haven't thought this through (but again, I'm happy to be proven wrong). > This is unrealistic. On the want majority of computers an app will only be run by 1 user. Focusing on handling multiple users is a more special case and is a distraction from the point I'm trying to make. What does this even mean? We're talking about user-specific state. So there's different state for each user, which means there are multiple users, by definition! So how is focusing on multiple users a distraction? It's the whole point... As I mentioned, on NixOS, the system-wide mutable state is already stored on /var/lib/<app>, which is what you are (redundantly) proposing. So we're just arguing about how to handle user-specific state, nothing else.