You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem: we need to use the container's gdb (for libc compatibility stuff, and probably utils have issues), but nix's XFCE needs nix stuff in the path.
Solution:
the PATH starts out with /run/workspace/bin last
instead of serving up symlinks, /run/workspace/bin serves up wrapper scripts that put /run/workspace/bin first in the PATH
the global pwn.college .bashrc changes the path to (in interactive mode) put /run/workspace/bin last
The effect: nix stuff runs with nix first in the path, things that the user launches that aren't nix stuff run with nix last in the path, allowing the challenge to sanely override nix utilities.
The text was updated successfully, but these errors were encountered:
The sketchiest part of this is relying on the global .bashrc being picked up. How does this work with other shells? How easy is it for user customizations to mess up loading that global .bashrc?
Maybe we could also add an alias like nix-gdb or similar to PATH as an easy way to access it.
We already rely on the global bashrc for other functionality (e.g., linux-luminarium heavily relies on this), so I think that's an okay risk. For other shells, we can probably hook equivalent things, but honestly, I'm most concerned about the "officially supported" bash setup.
Definitely agree with adding an alias for the common nix tools. I don't see any downsides there.
Problem: we need to use the container's
gdb
(for libc compatibility stuff, and probably utils have issues), but nix's XFCE needs nix stuff in the path.Solution:
The effect: nix stuff runs with nix first in the path, things that the user launches that aren't nix stuff run with nix last in the path, allowing the challenge to sanely override nix utilities.
The text was updated successfully, but these errors were encountered: