Best effort supplementary groups #8342
Merged
+122
−11
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There is no obvious good solution for this that has occured to anyone.
Co-authored-by: Guillaume Girol <[email protected]>
8 tasks
github-actions
bot
added
the
with-tests
This gets in the way of the tests running in parallel.
roberth
reviewed
May 18, 2023
src/libstore/globals.hh
Outdated
| R"( | ||
| Whether to drop supplementary groups when building with sandboxing. | ||
| This is normally a good idea if we are root and have the capability to | ||
| do so. |
There was a problem hiding this comment.
When is it not? I think we should warn about negative groups (if that's the right name for it); groups that when you're a member, you have fewer capabilities rather than more.
It would guess for it to be rare that the daemon would start as root but have a negative group, but I don't think we are free to assume just assume that and be quiet about it here.
There was a problem hiding this comment.
@roberth The problem is I don't think Unix has any clue what groups are "covariant", "contravariant", or "invariant": it depends on how they are used, and none of the LWM stuff on this mention any attempt to annotate the intent of the group on the group itself.
Unix is thus stuck with the pessimistic assumption that all groups are invariant, and only privilaged users can take them on or drop them alike.
It's extremely mediocre :/
There was a problem hiding this comment.
I would love to yell ask nicely on the LKML about all this:
- Why no way to annotate that info on the group, backwards compatibly?!
- Why do all the groups of a user need to be mapped into the user namespace in the first place?!
- Why does creating a mount namespace require a user namespace in the first place?!
But I think these are yak shaves not yet fitting in anyone's budget :).
There was a problem hiding this comment.
We could document our opinion, "open letter" style.
contravariant
That corresponds to my "negative". Not sure which is better. Something "anti-..." could fit and be more explicit. Needs more thought or more reading, or anything will do.
There was a problem hiding this comment.
Yeah I think postive/negative is better than co-/contrainvariant :), but then there is "invariant" too, and what does that map to? "Neutral" sounds more innocuous, like "bivariant" to me.
There was a problem hiding this comment.
Going back to the original question, I am actually fine with Nix assuming all groups are "positive", and always trying to drop groups. Non-positive ones are gross to me and I have little interest in trying to support them.
The real question question is if that operation fails, is it a fatal error or not? That is what feels to me like like a question that ultimately needs to be in the user's not Nix's hand.
(To simply unblock myself writing tests, and also for backwards compat since Nix didn't try to do the operation as non-root before, I made the option on whether to attempt the option. I have issue to instead make the setting about what to do if the operation fails with EPERM or whatever. Non-root could attempt the operation anyways, after all, it's possible to have the CAP_SETGID without being root so it might in fact succeed.)
thufschmitt
added
the
idea approved
|
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-06-22-nix-team-meeting-minutes-65/29643/1 |
Ericson2314
commented
Jul 11, 2023
There was a problem hiding this comment.
@benradf's changes look good to me in this PR. The only issue is now the test is being skipped.
Co-authored-by: Valentin Gagarin <[email protected]>
Co-authored-by: Valentin Gagarin <[email protected]>
benradf
approved these changes
Jul 17, 2023
thufschmitt
approved these changes
Jul 17, 2023
7 tasks
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this pull request
Jul 24, 2023
The motivation for this is basically explained in the contribution guide, as guidance on how to design features like this going forward. In short, I think it is confusing for operations acting on the default profile to *always* do something different based on whether the user is regular or root. Instead, this makes there be flags which are (from the vantage point of today) "do the root default" vs "do the regular user" default. This make the situation teachable: we can point to the flags, and the conditional default, as *exactly* what varies between the root and non-root cases. And by manually specifying enough flags, we can ensure those defaults are overridden and Nix will indeed do the same thing (or fail trying). This is similar to the logic behind the supplementary group setting (NixOS#8342), which I also discuss in this new section of the contribution guide as a second example.
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this pull request
Jul 24, 2023
The motivation for this is basically explained in the contribution guide, as guidance on how to design features like this going forward. In short, I think it is confusing for operations acting on the default profile to *always* do something different based on whether the user is regular or root. Instead, this makes there be flags which are (from the vantage point of today) "do the root default" vs "do the regular user" default. This make the situation teachable: we can point to the flags, and the conditional default, as *exactly* what varies between the root and non-root cases. And by manually specifying enough flags, we can ensure those defaults are overridden and Nix will indeed do the same thing (or fail trying). This is similar to the logic behind the supplementary group setting (NixOS#8342), which I also discuss in this new section of the contribution guide as a second example. Instead of creating the default dirs in `getDefaultProfile` (which is a bit odd if the symlink points elsewhere), create the profile dir for the chosen profile in `createGeneration`. That seems more appropriate and keeps the test added in e997512 (where the profiles are deleted but the symlink isn't) working.
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this pull request
Aug 2, 2023
The motivation for this is basically explained in the contribution guide, as guidance on how to design features like this going forward. In short, I think it is confusing for operations acting on the default profile to *always* do something different based on whether the user is regular or root. Instead, this makes there be flags which are (from the vantage point of today) "do the root default" vs "do the regular user" default. This make the situation teachable: we can point to the flags, and the conditional default, as *exactly* what varies between the root and non-root cases. And by manually specifying enough flags, we can ensure those defaults are overridden and Nix will indeed do the same thing (or fail trying). This is similar to the logic behind the supplementary group setting (NixOS#8342), which I also discuss in this new section of the contribution guide as a second example. Instead of creating the default dirs in `getDefaultProfile` (which is a bit odd if the symlink points elsewhere), create the profile dir for the chosen profile in `createGeneration`. That seems more appropriate and keeps the test added in e997512 (where the profiles are deleted but the symlink isn't) working.
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this pull request
Aug 11, 2023
The motivation for this is basically explained in the contribution guide, as guidance on how to design features like this going forward. In short, I think it is confusing for operations acting on the default profile to *always* do something different based on whether the user is regular or root. Instead, this makes there be flags which are (from the vantage point of today) "do the root default" vs "do the regular user" default. This make the situation teachable: we can point to the flags, and the conditional default, as *exactly* what varies between the root and non-root cases. And by manually specifying enough flags, we can ensure those defaults are overridden and Nix will indeed do the same thing (or fail trying). This is similar to the logic behind the supplementary group setting (NixOS#8342), which I also discuss in this new section of the contribution guide as a second example. Instead of creating the default dirs in `getDefaultProfile` (which is a bit odd if the symlink points elsewhere), create the profile dir for the chosen profile in `createGeneration`. That seems more appropriate and keeps the test added in e997512 (where the profiles are deleted but the symlink isn't) working.
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this pull request
Aug 21, 2023
The motivation for this is basically explained in the contribution guide, as guidance on how to design features like this going forward. In short, I think it is confusing for operations acting on the default profile to *always* do something different based on whether the user is regular or root. Instead, this makes there be flags which are (from the vantage point of today) "do the root default" vs "do the regular user" default. This make the situation teachable: we can point to the flags, and the conditional default, as *exactly* what varies between the root and non-root cases. And by manually specifying enough flags, we can ensure those defaults are overridden and Nix will indeed do the same thing (or fail trying). This is similar to the logic behind the supplementary group setting (NixOS#8342), which I also discuss in this new section of the contribution guide as a second example. Instead of creating the default dirs in `getDefaultProfile` (which is a bit odd if the symlink points elsewhere), create the profile dir for the chosen profile in `createGeneration`. That seems more appropriate and keeps the test added in e997512 (where the profiles are deleted but the symlink isn't) working.
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this pull request
Aug 25, 2023
The motivation for this is basically explained in the contribution guide, as guidance on how to design features like this going forward. In short, I think it is confusing for operations acting on the default profile to *always* do something different based on whether the user is regular or root. Instead, this makes there be flags which are (from the vantage point of today) "do the root default" vs "do the regular user" default. This make the situation teachable: we can point to the flags, and the conditional default, as *exactly* what varies between the root and non-root cases. And by manually specifying enough flags, we can ensure those defaults are overridden and Nix will indeed do the same thing (or fail trying). This is similar to the logic behind the supplementary group setting (NixOS#8342), which I also discuss in this new section of the contribution guide as a second example. Instead of creating the default dirs in `getDefaultProfile` (which is a bit odd if the symlink points elsewhere), create the profile dir for the chosen profile in `createGeneration`. That seems more appropriate and keeps the test added in e997512 (where the profiles are deleted but the symlink isn't) working.
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this pull request
Aug 25, 2023
The motivation for this is basically explained in the contribution guide, as guidance on how to design features like this going forward. In short, I think it is confusing for operations acting on the default profile to *always* do something different based on whether the user is regular or root. Instead, this makes there be flags which are (from the vantage point of today) "do the root default" vs "do the regular user" default. This make the situation teachable: we can point to the flags, and the conditional default, as *exactly* what varies between the root and non-root cases. And by manually specifying enough flags, we can ensure those defaults are overridden and Nix will indeed do the same thing (or fail trying). This is similar to the logic behind the supplementary group setting (NixOS#8342), which I also discuss in this new section of the contribution guide as a second example. Instead of creating the default dirs in `getDefaultProfile` (which is a bit odd if the symlink points elsewhere), create the profile dir for the chosen profile in `createGeneration`. That seems more appropriate and keeps the test added in e997512 (where the profiles are deleted but the symlink isn't) working.
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this pull request
Dec 20, 2023
The motivation for this is basically explained in the contribution guide, as guidance on how to design features like this going forward. In short, I think it is confusing for operations acting on the default profile to *always* do something different based on whether the user is regular or root. Instead, this makes there be flags which are (from the vantage point of today) "do the root default" vs "do the regular user" default. This make the situation teachable: we can point to the flags, and the conditional default, as *exactly* what varies between the root and non-root cases. And by manually specifying enough flags, we can ensure those defaults are overridden and Nix will indeed do the same thing (or fail trying). This is similar to the logic behind the supplementary group setting (NixOS#8342), which I also discuss in this new section of the contribution guide as a second example. Instead of creating the default dirs in `getDefaultProfile` (which is a bit odd if the symlink points elsewhere), create the profile dir for the chosen profile in `createGeneration`. That seems more appropriate and keeps the test added in e997512 (where the profiles are deleted but the symlink isn't) working.
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this pull request
May 22, 2024
The motivation for this is basically explained in the contribution guide, as guidance on how to design features like this going forward. In short, I think it is confusing for operations acting on the default profile to *always* do something different based on whether the user is regular or root. Instead, this makes there be flags which are (from the vantage point of today) "do the root default" vs "do the regular user" default. This make the situation teachable: we can point to the flags, and the conditional default, as *exactly* what varies between the root and non-root cases. And by manually specifying enough flags, we can ensure those defaults are overridden and Nix will indeed do the same thing (or fail trying). This is similar to the logic behind the supplementary group setting (NixOS#8342), which I also discuss in this new section of the contribution guide as a second example. Instead of creating the default dirs in `getDefaultProfile` (which is a bit odd if the symlink points elsewhere), create the profile dir for the chosen profile in `createGeneration`. That seems more appropriate and keeps the test added in e997512 (where the profiles are deleted but the symlink isn't) working.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
There is no obvious good solution for this that has occurred to anyone.
Provide a way to hack around trying to drop supplementary groups when root.
Context
Currently,
will fail when the outside user is not root, because one doesn't actually have the permission to call
setgroups. This provides a work-around to skip that step.Checklist for maintainers
Maintainers: tick if completed or explain if not relevant
tests/**.shsrc/*/teststests/nixos/*Priorities
Add 👍 to pull requests you find important.