-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix profile backwards compat #8009
base: master
Are you sure you want to change the base?
Conversation
Upon initializing a local or daemon store, create (if it doesn't exist) a link from `${NIX_STATE_DIR}/profiles/per-user/${currentUser}` to the actual profiles dir (under the user's XDG state dir). This is a bit involved for the daemon as 1. We need the client to pass the path to its profile directory (since the daemon can't guess it) 2. We don't want the client to be able to impersonate another user as that would give it the ability to create a link from `${NIX_STATE_DIR}/profiles/per-user/${otherUser}` to any place in the file system, effectively controlling this other user's environment for anything that doesn't use the new profiles directory. So the way we do that is that is that 1. The `userName` is taken from the Unix socket used for the connection (if there's one. Otherwise this doesn't make sense any way) 2. The creation of the symlink is triggered by a dedicated protocol command which also passes the path to the user's profile directory. Using a custom command just for that is a bit nasty, but that also seems to be the most reasonable solution.
Hm, it seems to me that this introduces a lot of complexity, and the daemon is back to creating stuff on behalf of the user. So we're basically back to where we started, only with an additional protocol call. So maybe it's better to revert #5226 after all... |
I still think we should just change the default so:
This is a "soft revert" that will allow us to continue fixing issues with the home directory channels while not effecting non-adventurous users. Or, just combine with |
Not exactly, because the daemon doesn't have to impersonate the user. But yeah, this adds a lot of complexity indeed. We could possibly avoid the extra protocol call by bundling that into @Ericson2314 that's not really feasible (not with an equivalent level of complexity at least) because that still means that the client must send it's profile directory to the daemon if it wants it to be used. |
FWIW Home Manager now should work OK with Nix 2.14 (see nix-community/home-manager#3742). So the new behavior is not a blocker for us. The main issue for me, is that it is unclear whether The second main issue is that the documentation still seems to refer to the |
@thufschmitt Sorry, I completely missed that the original PR didn't continue to support the old location on an ongoing basis, but instead migrated it to the new location (though I don't fully understand how it does that yet). |
It doesn't. The logic is mostly the same as the old one (well, the one of
After #7993 it will. And since this PR makes the old profile directory a symlink to the new one, both should be usable interchangeably. |
Just expanding a bit on that: The problem with using the client-side profile only if it exists is that for this to be useful at all, the daemon must know whether it exists or not to know whether it should create the one under |
Err but @rycee made it use |
I'll have to double-check (just have 1min between two meetings right now), but I think this will work just fine since |
@thufschmitt Ah, I see the confusion now. Unfortunately, Home Manager does not completely take over the user's profile since we still want the user to be able to use the regular So, Ideally, it would be nice if it were possible to set up HM to have its profile show up in |
@rycee Yes what you say matched my understanding. Absent a new way to tell I am leaning towards not having a backwards compat trick but either one of:
|
Discussed in the Nix team Meeting:
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-03-10-nix-team-meeting-minutes-39/26279/1 |
void createLegacyProfileLink(Path oldProfile, Path newProfile) | ||
{ | ||
if (pathExists(oldProfile)) | ||
return; | ||
createDirs(dirOf(oldProfile)); | ||
replaceSymlink(newProfile, oldProfile); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make naming consistent with the rest of PR, and less confusing
void createLegacyProfileLink(Path oldProfile, Path newProfile) | |
{ | |
if (pathExists(oldProfile)) | |
return; | |
createDirs(dirOf(oldProfile)); | |
replaceSymlink(newProfile, oldProfile); | |
} | |
void createLegacyProfilesLink(Path oldProfilesDir, Path newProfilesDir) | |
{ | |
if (pathExists(oldProfilesDir)) | |
return; | |
createDirs(dirOf(oldProfilesDir)); | |
replaceSymlink(newProfilesDir, oldProfilesDir); | |
} |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/tweag-nix-dev-update-46/26872/1 |
Motivation
Fix the backwards-compat hack that was butchered as part of #5226
/cc @rycee @ncfavier
Context
Upon initializing a local or daemon store, create (if it doesn't exist) a link from
${NIX_STATE_DIR}/profiles/per-user/${currentUser}
to the actual profiles dir (under the user's XDG state dir).This is a bit involved for the daemon as
${NIX_STATE_DIR}/profiles/per-user/${otherUser}
to any place in the file system, effectively controlling this other user's environment for anything that doesn't use the new profiles directory.So the way we do that is that is that:
userName
is taken from the Unix socket used for the connection (if there's one. Otherwise this doesn't make sense any way)Using a custom command just for that is a bit nasty, but that also seems to be the most reasonable solution.
Checklist for maintainers
Maintainers: tick if completed or explain if not relevant
tests/**.sh
src/*/tests
tests/nixos/*
Priorities
Add 👍 to pull requests you find important.