Skip to content
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.

Sign up for GitHub

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

Jump to bottom

virtualbox: discover extension packs at runtime #71127

Closed
wants to merge 4 commits into from
Closed

virtualbox: discover extension packs at runtime #71127

wants to merge 4 commits into from
+85 −39

Conversation

flokli
Copy link
Contributor

@flokli flokli commented Oct 14, 2019 •
edited
Loading

Motivation for this change

Currently, virtualbox with extension pack and virtualbox without extension pack need to be build separately, because it's just an argument in the same derivation leaving to a different installPhase.

As the extension pack is unfree (and unfree isn't built by hydra), this means users with extension pack enabled need to compile virtualbox by themselves quite often.

This changes virtualbox to load extension packs from a environment variable VBOX_EXTPACK_DIR, so we can build virtualbox once by hydra, and let users of the extension pack just use the wrapper in front of it.

See #34796 (comment) for the original idea.

However, this might not work with enabled hardening, as the environment variable will be ignored. To fix it there, we might want to hardcode vboxExtpackDir to some imperative location changed during configuration switch, or replace the wrapper with something binary-patching the original virtualbox.

This draft PR is also to get the discussion started.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.
Notify maintainers

cc @ambrop72 @xeji @cdepillabout

Sorry, something went wrong.

@ofborg ofborg bot added 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: module (update) This PR changes an existing module in `nixos/` labels Oct 14, 2019
@flokli flokli force-pushed the virtualbox-extpack branch from d825d86 to 5c71013 Compare October 14, 2019 14:42
@ofborg ofborg bot requested review from svanderburg and cdepillabout October 14, 2019 14:46
@ofborg ofborg bot added 11.by: package-maintainer This PR was created by the maintainer of the package it changes 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 11-100 labels Oct 14, 2019
@worldofpeace
Copy link
Contributor

TBH, what's really gained in hardening if it's from an imperative location? Isn't that just as poor as the environment variable?

@ambrop72
Copy link
Contributor

I suggest to solve this using a wrapper in one of the following ways:

  • Make a trivial wrapper that sets VBOX_EXTPACK_DIR and exec's the real binary. This wrapper is itself wrapped by the setuid wrapper. It must be written in C, not bash, as bash refuses to run setuid.
  • Extend the capabilities of the setuid wrapper system to allow the wrapper to set environment variables.

@ambrop72
Copy link
Contributor

@worldofpeace It can still be secure if we are careful that both with and without the extension pack, the trusted wrapper always sets VBOX_EXTPACK_DIR. This way no matter what VBOX_EXTPACK_DIR is when calling the setuid program, it will be overwritten with the hardcoded value by wrapper.

matthewbauer
matthewbauer reviewed Oct 14, 2019
View reviewed changes
pkgs/applications/virtualization/virtualbox/extpack.nix
# Checksums can also be found at https://www.virtualbox.org/download/hashes/${version}/SHA256SUMS
let value = "27a0956940654b0accf4d79692078bd496d9f062e4ed3da69e5421cba8d1e444";
in assert (builtins.stringLength value) == 64; value;
stdenv.mkDerivation rec {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can’t we keep the fetchurl here?

Copy link
Contributor Author

@flokli flokli Oct 16, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC, Virtualbox wants to have that $pname in VBOX_EXTPACK_DIR. We could do all the extracting and moving around in the wrapper, but…

I also like it being a proper derivation, with all the ways to modify, fixup and patch(elf) it.

On top of that, we could start supporting multiple virtualbox extension packs.
The virtualbox derivation currently also produces a $out/libexec/virtualbox/ExtensionPacks/Oracle_VBoxDTrace_Extension_Pack - I'm not sure if anybody is using that, but moving it to a separate output and adding it to the list of exposed extpacks sounds useful.

@worldofpeace
Copy link
Contributor

worldofpeace commented Oct 14, 2019 •
edited
Loading

Those are great ideas @ambrop72 ✨
Now if only makeWrapper was a C wrapper too... 😄

@SRGOM
Copy link
Member

SRGOM commented Oct 29, 2019

I feel stupid commenting when there are much more knowledgeable people here but I have a question about:

we might want to hardcode vboxExtpackDir to some imperative location changed during configuration switch

Isn't the location of guest additions always known (even if guest additions aren't compiled)? The .drv derivation itself is something that hydra wouldn't mind making and that's what decides the store location ..., so wouldn't it work to compute what path to hardcode?

I should probably shut up ...

@flokli
Copy link
Contributor Author

flokli commented Nov 28, 2019

closing due to #74503. I'll keep the branch around if anybody wants to pick this up.

@flokli flokli closed this Nov 28, 2019
@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/virtualbox-keeps-getting-rebuilt/6612/4

@kini
Copy link
Member

kini commented Oct 13, 2024

FWIW, I've attempted to rebase this PR branch on the latest master: master...kini:nixpkgs:virtualbox-extpack

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@matthewbauer matthewbauer

@Mic92 Mic92

@NeQuissimus NeQuissimus

@worldofpeace worldofpeace

@svanderburg svanderburg

@cdepillabout cdepillabout

Assignees
No one assigned
Labels
6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: module (update) This PR changes an existing module in `nixos/` 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 11-100 11.by: package-maintainer This PR was created by the maintainer of the package it changes
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
8 participants
@flokli @worldofpeace @ambrop72 @SRGOM @nixos-discourse @kini @matthewbauer @Mic92