`sudo` does not work from within vscode-fhs

[waffle8946]

@Malix

So should we conclude it is impossible to make .fhs variants of editors be able to edit root files?

This was already said in the thread twice, but to be absolutely clear, yes, it’s impossible to use sudo within *.fhs for security reasons.

The workarounds were already provided as well.

`sudo` does not work from within vscode-fhs

It is impossible to use SUID applications from within user namespaces for good reason. Otherwise an unprivileged user could simply bind a crafted /etc/sudoers and become root.

`sudo` does not work from within vscode-fhs

The answer is pretty clear: All the Linux namespace wrappers (bubblewrap, NixOS user chroot, firejail, etc.) seem to enforce PR_SET_NO_NEW_PRIVS 5 which means suid binaries cannot be executed. Rightfully so, in my opinion, because suid binaries allow the jailed application to break out and elevate its privileges. I.e., for security reasons, this is not possible. If you want to run a command as root, you have to do it in a terminal not launched by vscode. Alternatively, you could use the vsc…

[anon23399578]

@Malix

This is interesting, is it documented somewhere as a best practice?

There’s the official wiki and the nixos-rebuild manual page (sorta).

[NobbZ]

@Malix

I need VSCode to be able to use its sync mechanism

Non-FHS should support that as well.

For now I assume that you could just change.

[Kin]

I don’t really understand the reluctance to consider this an actual issue. I’m fairly new to NixOS, but looking at the documentation for buildFHSEnv the goal doesn’t seem to be security or strong isolation but the ability to run applications which don’t natively support NixOS.

https://ryantm.github.io/nixpkgs/builders/special/fhs-environments/#sec-fhs-environments

It works similar to containerisation technology such as Docker or FlatPak but provides no security-relevant separation from the host system.

[waffle8946]

@Kin

buildFHSEnv | nixpkgs

This is not an official documentation site; you should only be looking at docs from nixos.org or nix.dev - in this case https://nixos.org/manual/nixpkgs/unstable/#sec-fhs-environments.

Anyway it’s explained more clearly in buildFHSEnv: binaries with capabilities cannot make use of them · Issue #217119 · NixOS/nixpkgs · GitHub.

Ultimately you are better off just using the regular vscode. I don’t really understand the copy-pasted desire to use vscode-fhs other than “someone else did so I must too.”

[Kin]

This is not an official documentation site; you should only be looking at docs from nixos.org or nix.dev - in this case Nixpkgs Reference Manual.

I don’t know what point you are trying to make, the text is exactly the same. I just quoted the docs that someone else did in this thread.

Ultimately you are better off just using the regular vscode. I don’t really understand the copy-pasted desire to use vscode-fhs other than “someone else did so I must too.”

The reasoning being entire workflows aren’t supported by it. What is the point of using an application when most of its capability won’t work without an ever increasing number of overrides and configuration hacks. We already have tools and workflows for working with/in vscode, and if Nix can’t support then its on Nix.

[waffle8946]

@Kin

I don’t know what point you are trying to make, the text is exactly the same.

The point is to stick to using official manuals instead of 2-year outdated sites.

@Kin

The reasoning being entire workflows aren’t supported by it. What is the point of using an application when most of its capability won’t work without an ever increasing number of overrides and configuration hacks.

If you need to run sudo and insist on using vscode-fhs, run it outside the fhs. We’re not going to fork the kernel and open a security hole just for this edge case. It’s that simple.

@hmenke

All the Linux namespace wrappers (bubblewrap, NixOS user chroot, firejail, etc.) seem to enforce PR_SET_NO_NEW_PRIVS which means suid binaries cannot be executed.

btw, buildFHSEnv is also a hack, so is the entirety of nix and NixOS, it’s just a matter of taste, maintainability, and security as to which hacks are tolerable.

[Kin]

It sounds like less a matter of taste and more-so inflexibility and platform incompetence. I don’t see the point of reproducibility when whole standard workflows aren’t supported. No one’s asking anyone to fork the kernel or introduce security vulnerabilities, just to simply treat this an actual issue and not “you’re doing it wrong”. I think this really shows the downsides of Nix, the Nix community, and I’m realizing its not the developer friendly OS I expected.

[waffle8946]

It’s a kernel limitation, as mentioned in the link I posted earlier and the quote I mentioned. I think it’s well-explained how you are basically asking for a security hole, and standard-for-you != standard. Though if you have a better solution to propose do so, it’s open source after all. But if you are just asking for everyone else to drop things and work on your problem for free, I think you will find limited success with that approach in any open-source community, especially after hurling insults

[Malix]

@NobbZ

Non-FHS should support that as well.

It doesn’t for extensions

@waffle8946

Ultimately you are better off just using the regular vscode. I don’t really understand the copy-pasted desire to use vscode-fhs other than “someone else did so I must too.”

Using and syncing extensions using VSCode alone and without nixification

Some environment wouldn’t work with nix (including VSCode web)

---

However, I understand the security implications of making sudo work from within a sandboxed .fhs package and the tradeoff using .fhs implies

[Michael-C-Buckley]

I use sync and assumed I needed the fhs edition. I swapped yesterday and the extensions were there, working on non-fhs one. I added a new one while on my windows work laptop. I’ll boot my personal up in a bit to check the changes.

[Malix]

I also have been told that extensions wouldn’t work without .fhs but I just tested and indeed, the non-fhs version also was able to install and sync extensions too

Then, I do not know any benefit of vscode.fhs compared to vscode