Adding setcap-wrapper functionality to Nix #16654
Conversation
|
@ixmatus, thanks for your PR! By analyzing the annotation information on this pull request, we identified @wkennington, @edolstra and @fpletz to be potential reviewers |
|
Interesting! I think there are at least 3 commits that are better squashed (MHO). |
| pkgs.stdenv.mkDerivation { | ||
| name = "setcap-wrapper"; | ||
| unpackPhase = "true"; | ||
| buildInputs = [ linuxHeaders_4_4 libcap libcap_ng ]; |
There was a problem hiding this comment.
It doesn't strike me as a particularly good idea to hardcode the linux header version here (linuxHeaders_4_4). Isn't there an attribute for the "current" kernel header package?
There was a problem hiding this comment.
Yes, you're right, that should just be linuxHeaders I believe. I had to specify a hard kernel header version because stable doesn't have the 4.4 headers in it (yet) I had to copy & inject the headers. I'll fix this.
|
Yeah a bunch can be squashed but I didn't do it not knowing how you guys On Fri, Jul 1, 2016 at 2:55 PM, Bjørn Forsman notifications@github.com
Parnell Springmeyer |
|
Awesome! Thanks a lot for your work! Will test later and give some more feedback. |
| owner = "nobody"; | ||
| group = "nogroup"; | ||
| setcap = true; | ||
| capabilities = "cap_net_raw+ep"; |
There was a problem hiding this comment.
Could we maybe use a nix list here? Is the format to specify the capabilities documented somewhere? May be worth mentioning where to find it in the description.
There was a problem hiding this comment.
@fpletz the format is documented in cap_from_text(3)
There was a problem hiding this comment.
I'll add some documentation about where one would find the capabilities format cap_from_text and setcap expect, great point.
|
This should be merged with the setuid wrapper so that we don't have to maintain two very similar programs, and bloat |
|
@edolstra that's a great idea. It was separated originally simply because we needed the feature and just wanted to inject it into our modules tree but now that you're saying this I definitely agree it should be unified. Additionally, we made significant improvements to the C wrapper program that the setuid C wrapper program should benefit from so I think it's very reasonable to merge these two features together. @edolstra would you like me to begin making those changes in this PR? Or close this one and open a new PR with the two features merged? I could also do them in a separate branch and open a PR to this branch so we can review the changes required to merge to the features, then once approved approve this PR. |
|
Just adding my 👍 for KDE, which could use a setcap wrapper (currently using a setuid wrapper). |
|
Okay cool. Because I haven't had a response on how maintainers want the PR for merging setuid-wrapper and setcap-wrapper I'm just going to branch off of this branch and submit a PR for THIS branch. |
|
@ixmatus Both options seem fine to me. Please just go ahead. Thanks a lot for your work. 👍 |
|
Just want to put a bump on this and say I look forward to having it in mainline. |
|
Thanks 😃 I'm almost done with merging the two wrapper functionalities On Jul 20, 2016 8:33 PM, "Graham Christensen" notifications@github.com
|
|
Sorry I've been MIA everyone - I have this 90% complete, just haven't found a few hours to work on this amongst all of the travel for work I've been doing. I should be able to finish this week so everyone can review. |
|
@joachifm how much time do I have before the 16.09 release? We've been swamped here but would love to see this in 16.09 so I can prioritize time for this if it's coming soon. |
|
@ixmatus the branch-off is scheduled for next week (I don't recall if branch-off is at last day of the month or 1st of the next one, so either wednesday or thursday). Is there anything we can do to help move things along? |
|
@joachifm okay thanks. I just saw the email message hiding in my folder from a month ago! Well, as this branch stands, it works. But I'm right in the middle of addressing @edolstra's feedback; I should be able to get to that this weekend. Though I will say that there's some production mileage on our own systems of the current formulation that his PR represents. As a suggestion, it might be "safer" to merge this one and run with it, then come back in after release and refactor. Though I know that's not preferable because it's easy to forget to do that... I'm proceeding with addressing his feedback, will try to knock it out over the weekend, and merging the two functionalities but if you feel like the above strategy (merging what is here now and works) is better, just let me know. |
|
@ixmatus so the only thing that's currently missing is unifying setcap and setuid? If so, my preference would be to merge it, but that's not my call to make. |
|
It's hard to make that trade-off. I've seen many times such refactorings don't happen in future, because bugs are just fixed and there's never enough initiative to rewrite/merge. This PR should follow the boyscout rule and refactor setuid-wrapper to introduce new functionality. |
|
👍 I'm working on finishing up the merged functionality today. On Aug 28, 2016 7:00 AM, "Domen Kožar" notifications@github.com wrote:
|
|
This looks really great. How did the merging go? Reviewed 6 of 7 files at r1, 1 of 1 files at r2. Comments from Reviewable |
|
Honestly, very slowly. I also moved to a new permanent residence this On Sun, Aug 28, 2016 at 9:40 PM, Graham Christensen <
Parnell Springmeyer |
|
I'm being given a day by my employer tomorrow (Wednesday) to knock this out, I'll be working on it then. Sorry for the delay everyone. |
|
Well, the 1st of this month has come - I made progress but I don't feel confident yet in the merged functionality, I want to refactor the code a bit more and do more testing. I think unless the freeze gets extended, this will have to wait until the next release or make it into a patch release. |
|
I'm continuing to work on it today so hopefully I can get something I feel confident about in today - but not sure if that's cutting it too close for the freeze. |
|
If the feature is complete and you're willing to fix any bugs in upcoming month, we can merge tgis today. |
|
@domenkozar yeah I am willing, I'll push to this branch in a few hours after a bit more testing. |
|
Thanks for the info. |
|
@bjornfor thank you for catching those mistakes! Is the test suite on Hydra something that can be run, say, on my own EC2 machine so that I could catch these mistakes next time while developing? Do we have developer documentation outlining how to run such a test suite? It would be nice to catch these things earlier. The list to attrset improvement was suggested by @edolstra in this PR and I like it better than the list-based approach as it keeps it consistent with the other APIs in NixOS that expose a similar interface. And yes, the only two programs I updated to use the new setcap feature are |
I know very little about how Hydra works, but I know a bunch of nixos tests exist in the nixos/tests directory. A single test can be run with |
|
Okay, I'll investigate using the test suite next time, thanks. Hmm I was also running |
|
@ixmatus: Yes, I have enabled extra services. And because I don't have enabled "all", there may very well be some places in nixos that are still broken due to this change... (Hence I wish this API change would have been handled a bit more carefully...) |
|
@bjornfor this API change / PR has been around for more than six months and I'm completely engaged in helping to fix things. What do you suggest I should do different now or next time to make this more graceful or careful? Yes that documentation is stale, I will fix it ASAP. Thanks for pointing it out. |
|
Already done: ce0a52f |
|
Also, maintainers appeared unphased that travis reports a red X on builds of PRs so I was assuming that the builds are broken somewhere and it is acknowledged but not blocking merges, or builds are happening elsewhere (on hydra?) that validate work to be merged. I'm very open to helping with project short-comings (to make merges safer) and receiving constructive feedback on how I could have gone about something better or different. |
|
I will try enabling all services and building on my EC2 instance to see if other places fail; I'm going to |
|
Also, I'm sorry my change is breaking a few things. I will try a wider build and clean up whatever fails, I will take ownership of not having thought to do that entirely for all my dev test builds :) |
|
@ixmatus: Unfortunately Hydra doesn't build PRs (yet). So the (real) CI only catches problems after the fact. (Travis CI doesn't check much compared to Hydra.) This is IMHO one of the biggest problems with nixpkgs development. (Along with "who decides what"...) There is no automation to prevent untested features entering master, and people generally don't care enough (IMHO) about stability on master. (And there are many committers -- both good and bad!) I think NixOS/hydra#95 is very important. And whatever we need to get to a place where Hydra is more or less a "gateway" for code to enter master branch. Some might argue that problems are caught within "reasonable" time with the current setup. But I think we should strive for better quality on master branch :-) |
|
@bjornfor: okay I ran a My build succeeded with those lines commented out and I left a comment with the failure. I believe gale can be fixed so I can enable it and test that. I'm not positive what the And finally I think I'm covering the build pretty well here. I will switch my system to this config and check all of the executables being wrapped to make sure it went the way it was supposed to. A couple of modules have some tricky logic for conditionally including certain executables in the wrappers attrset so I'll to spend some time tonight picking that apart and making sure those code paths are exercised. Also, yes, I think better CI would help NixOS a lot; I have experience working with CI for NixOS systems because we've had to make it as smooth as possible at work where we're using NixOS. I'm more than happy to help with this but not quite sure where to start or if I have permissions to do this kind of work or what is currently being worked on. |
|
Umm, for future merges I would appreciate some kind of commit cleanup. Ideally into a sequence of reasonably small commits that can be individually reviewed and with clear descriptive commit messages. I happened to think of this while browsing the log since my last pull to keep myself up to date. Was having a difficult time with commits such as |
|
+1 for flatting commit history next time, this is also hard to back out |
Good! I don't know where to start either. IMHO, another big pain point of NixOS is exactly the lack of knowing who has power to do what, and who has the final say in matters... and that some core people are overloaded (or so I've heard). |
|
Yeah, do we squash-merge PRs (or is there a community guideline against that?) That would have at least cleaned it up going into That feedback for general PR hygiene is totally fair and I completely understand the reason, it's painful for me when I have to review PRs that aren't cleaned up or broken into smaller pieces. This PR has seen a lot of churn (the initial PR had a single clean commit that was squashed) and my personal and work life are such that I don't always have the time I want to devote to OSS projects and I was worried I'd lose momentum again if I started juggling multiple PRs and maintaining those PRs against So, I appreciate people's patience with the messy PR and commit history and I'll try to do better next time, free-time and momentum permitting. |
|
(And there are many committers -- both good and bad!)
I take offense with the statement that any of the committers can be
classified into either of these categories! (well, except Eelco,
obviously, he is good by definition)
I think NixOS/hydra#95 is very important. And whatever we need to get to a place where Hydra is more or less a "gateway" for code to enter master branch.
Hm, what will be the live non-gridlocked branch then? Some updates have
large but rarely used reverse dependencies…
|
Oh, that's not what I meant! (Sorry for bad wording.) I mean that many committers to the main repo is both a blessing and a curse. (I think a hierarchical approach, like the topic specific sub-trees of Linux development is a better model. AFAIK, only Linus has commit access to the main repo.)
You mean where to push updates that will cause some regressions that negatively affect some, however few, people? Difficult question, but I think we have to start by knowing the effects of a change before it enters master. Then we can decide on whether that change should go in or not. We already have a definition of a "working" master branch: it's where Hydra builds pass and a new channel is produced. And this "working" master branch still has many packages in a broken state, but those packages are not blockers. |
|
Oh, that's not what I meant! (Sorry for bad wording.) I mean that many committers to the main repo is both a blessing and a curse. (I think a hierarchical approach, like the topic specific sub-trees of Linux development is a better model. AFAIK, only Linus has commit access to the main repo.)
I think hierarchical model is nice, it also needs more contributors than
we have now — I have recently checked one of the Linux releases, and the
number of people directly sending changes to Linus Torvalds is larger
than the number of committers in NixPkgs. The total number of
contributors to a single Linux kernel release is higher than the total
number of contributors across NixPkgs history.
When some area does have multiple people who can be reasonably declared
maintainers, I am all for encouraging the maintainers to set the rules.
For most packages I maintain I support people committing improvements
if they use the package, tested the improvements and do not know any
negatives.
You mean where to push updates that will cause some regressions that negatively affect _some_, however few, people?
You mean known bad effects. In that case we usually provide multiple
options in Nixpkgs until nobody admits using them.
I ask about running Maxima on fresh SBCL without waiting for Hydra to
check that ACL2 didn't get broken by the update. Also, how do we update
libxml2 without drowning in merge conflicts.
|
The replacements matched to much due to wrapperDir having `/bin` in its path now. cc #16654
Janik-Haag
added
the
12. first-time contribution
This makes setuid wrappers not fail after upgrading. references NixOS#23641, NixOS#22914, NixOS#19862, NixOS#16654 (cherry picked from commit e82baf0)
Motivation for this change
Resolves #6768
Setting capabilities on programs is desirable over
setuidbecause it improves the granularity of security. Nix wasn't able to supportsetcap-wrappersin the style ofsetuid-wrappersuntil recently when the Linux 4.4 kernel was added. Linux 4.3 included a capability named Ambient which enables a wrapper program to propagate its capabilities to an execv'ed program.This PR adds support for setcap-wrappers (with notable improvements to the wrapper program over
setuid-wrapper.c) and adds a conditional task that setspingandping6to be setcap wrapped if the kernel is at-least 4.3, if not then we default to the setuid behavior.Things done
(nix.useChroot on NixOS,
or option
build-use-chrootinnix.confon non-NixOS)
nix-shell -p nox --run "nox-review wip"./result/bin/), NOTE: only tested ping and ping6I tested both a sub 4.3 kernel (it defaulted to the setuid'ed
pingandping6) and with a 4.4 kernel (it defaulted to setcap'edpingandping6).