Can anyone explain why chroot requires root privileges in the first place? Because from my understanding it seems like it should only restrict what you can do rather than grant any new abilities.
RStudio Server[0] 1.3 and older hard-coded a number of paths, such as the path for storing temporary files: Instead of looking for the TMPDIR environment variable (as specified by POSIX[1]), R Studio Server would always use /tmp. That is extremely annoying, because we set TMPDIR to a path on fast local storage (SATA or NVMe SSDs) that the job scheduler cleans up at the end of the compute job.
We do have a last-resort mechanism using pam_namespace[2], such that a user going to `/tmp` actually takes them to `/namespace/tmp/${username}`, but that is per-user, not per-job. If a user has two R Studio jobs, and those two jobs landed on the same host, there would be trouble.
So, we used PRoot to wrap R Studio, with /tmp bind-mounted to a directory under TMPDIR.
A similar tool for this user-space bind-mount is https://github.com/fritzw/ld-preload-open, which relies on LD_PRELOAD to overwrite common libc functions. Thus this is less reliable as the presented tool which uses ptrace, but it still works reasonably well (I run e.g. PyCharm with it).
Thanks for sharing this! I had to do exactly the same thing some 10 years ago to get an Oracle instance up and running again. Oracle insisted on using the /tmp location, despite being installed on a different drive, and the disk was full. As I had access to the Oracle system user, but not to the DBA user to change any configuration, I built a similar shared lib and preloaded it to the script. Worked like a charm! Happy to know that there is something _slightly more streamlined_ to do that now.
Termux has now a nice wrapper (manager?) for proot [1]. I once wanted to submit a wrapper but got an angry response as the first comment to my PR and it was closed. Guess enough people did that until they decided maybe it's not a bad idea after all.
Ah no, sorry I was so lost in my thoughts and explained badly.
I was taking in the context of Termux app for Android, nothing to do with proot itself. Termux uses apt and deb repos, and provides a patched proot. I wanted to add a package similar to one I linked.
Ah! Finally I see a way to try nix (the package manager) on my existing installation without it requiring access to the root directory and other such stuff!
I don't recommend using Nix inside PRoot unless this is your only option (e.g.: Android, since there are no user namespaces). The reason for that is that Nix is syscall heavy and using it in PRoot will be slow, really slow.
As someone said, the wiki [1] has some interesting options. From the options I used nix-user-chroot [2] with great success, and while the tool is unmaintained it should still work. It uses Linux's user namespaces instead of intercepting syscalls, and this makes the performance pretty much identical to native.
If you want more control like PRoot offers, I recommend bubblewrap instead [2].
Another option undocumented is to just grab a recent nix binary somewhere and run. It will automatically create the Nix store inside `$HOME/.local/share/nix` (if I am not mistaken) and use user namespaces to mount to it. However the last time I tried this didn't work well for a few things (e.g.: Home-Manager), so in general I still think nix-user-chroot is a better choice.
Unrelated, but does anyone know what's the deal between wiki.nixos.org and nixos.wiki? The former appears to be actually functional, but the latter ranks much higher in search engines and seems to be incorrectly treated by them as the primary source.
nixos.wiki was the primary wiki before NixOS really had an official one. Now there is the official wiki.nixos.org and the NixOS foundation asked the nixos.wiki maintainer to cooperate on the new wiki but they refused. Now there are multiple problems[1] with nixos.wiki and the maintainer in unresponsive so although unfortunately it's ranked higher in search results, in my experience you'll get better information on the official wiki.
Because nixos.wiki was the primary source, until very recently. Then, wiki.nixos.org was introduced, and mass edits were made (without the owner of nixos.wiki being ok with that) trying to redirect people from nixos.wiki to wiki.nixos.org, and now both co-exist.
Reminds me a bit the archlinux.fr vs wiki.archlinux.org fr wiki situation from 10 years ago.
Unless I am mistaken this cannot elide over the fundamental protections Android enforce which make it impossible to do cross-device symlinks to external SD cards in a non-rooted Android: the outer kernel blocks this, even though you can cd into the paths.
If (for example) you can overlay/union mount and have a synthetic upper layer FS which manages things, I could use this.
`guix pack` can create bundles that use a static proot to make them relocatable:
https://hpc.guix.info/blog/2017/10/using-guix-without-being-...
It also supports other more performant ways, but in some situations proot is the best choice.
Can anyone explain why chroot requires root privileges in the first place? Because from my understanding it seems like it should only restrict what you can do rather than grant any new abilities.
Here's an example of how we've used this.
RStudio Server[0] 1.3 and older hard-coded a number of paths, such as the path for storing temporary files: Instead of looking for the TMPDIR environment variable (as specified by POSIX[1]), R Studio Server would always use /tmp. That is extremely annoying, because we set TMPDIR to a path on fast local storage (SATA or NVMe SSDs) that the job scheduler cleans up at the end of the compute job.
We do have a last-resort mechanism using pam_namespace[2], such that a user going to `/tmp` actually takes them to `/namespace/tmp/${username}`, but that is per-user, not per-job. If a user has two R Studio jobs, and those two jobs landed on the same host, there would be trouble.
So, we used PRoot to wrap R Studio, with /tmp bind-mounted to a directory under TMPDIR.
[0]: https://www.rstudio.com/products/rstudio/download-server/
[1]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
[2]: https://linux.die.net/man/8/pam_namespace
A similar tool for this user-space bind-mount is https://github.com/fritzw/ld-preload-open, which relies on LD_PRELOAD to overwrite common libc functions. Thus this is less reliable as the presented tool which uses ptrace, but it still works reasonably well (I run e.g. PyCharm with it).
Thanks for sharing this! I had to do exactly the same thing some 10 years ago to get an Oracle instance up and running again. Oracle insisted on using the /tmp location, despite being installed on a different drive, and the disk was full. As I had access to the Oracle system user, but not to the DBA user to change any configuration, I built a similar shared lib and preloaded it to the script. Worked like a charm! Happy to know that there is something _slightly more streamlined_ to do that now.
Termux has now a nice wrapper (manager?) for proot [1]. I once wanted to submit a wrapper but got an angry response as the first comment to my PR and it was closed. Guess enough people did that until they decided maybe it's not a bad idea after all.
[1]: https://github.com/termux/proot-distro
> I once wanted to submit a wrapper but got an angry response as the first comment to my PR and it was closed.
I don't follow; you made a PR to add this functionality to proot itself?
Ah no, sorry I was so lost in my thoughts and explained badly.
I was taking in the context of Termux app for Android, nothing to do with proot itself. Termux uses apt and deb repos, and provides a patched proot. I wanted to add a package similar to one I linked.
Great name in french
Ah! Finally I see a way to try nix (the package manager) on my existing installation without it requiring access to the root directory and other such stuff!
I don't recommend using Nix inside PRoot unless this is your only option (e.g.: Android, since there are no user namespaces). The reason for that is that Nix is syscall heavy and using it in PRoot will be slow, really slow.
As someone said, the wiki [1] has some interesting options. From the options I used nix-user-chroot [2] with great success, and while the tool is unmaintained it should still work. It uses Linux's user namespaces instead of intercepting syscalls, and this makes the performance pretty much identical to native.
If you want more control like PRoot offers, I recommend bubblewrap instead [2].
Another option undocumented is to just grab a recent nix binary somewhere and run. It will automatically create the Nix store inside `$HOME/.local/share/nix` (if I am not mistaken) and use user namespaces to mount to it. However the last time I tried this didn't work well for a few things (e.g.: Home-Manager), so in general I still think nix-user-chroot is a better choice.
[1]: https://wiki.nixos.org/wiki/Nix_Installation_Guide, linking to the official one
[2]: https://github.com/containers/bubblewrap
[3]: https://wiki.nixos.org/wiki/Nix_Installation_Guide#nix-user-...
https://nixos.wiki/wiki/Nix_Installation_Guide discusses that a bit more (also other solutions)
Unrelated, but does anyone know what's the deal between wiki.nixos.org and nixos.wiki? The former appears to be actually functional, but the latter ranks much higher in search engines and seems to be incorrectly treated by them as the primary source.
nixos.wiki was the primary wiki before NixOS really had an official one. Now there is the official wiki.nixos.org and the NixOS foundation asked the nixos.wiki maintainer to cooperate on the new wiki but they refused. Now there are multiple problems[1] with nixos.wiki and the maintainer in unresponsive so although unfortunately it's ranked higher in search results, in my experience you'll get better information on the official wiki.
[1] https://wiki.nixos.org/wiki/FAQ#Why_is_there_a_new_wiki?_Wha...?
Because nixos.wiki was the primary source, until very recently. Then, wiki.nixos.org was introduced, and mass edits were made (without the owner of nixos.wiki being ok with that) trying to redirect people from nixos.wiki to wiki.nixos.org, and now both co-exist.
Reminds me a bit the archlinux.fr vs wiki.archlinux.org fr wiki situation from 10 years ago.
Unless I am mistaken this cannot elide over the fundamental protections Android enforce which make it impossible to do cross-device symlinks to external SD cards in a non-rooted Android: the outer kernel blocks this, even though you can cd into the paths.
If (for example) you can overlay/union mount and have a synthetic upper layer FS which manages things, I could use this.
proot works by hijacking and altering syscalls. So maybe you could emulate the symlink yourself, by altering the file paths at ptrace level?
Thinking more, maybe it works out of the box? Just mount the overlays (there's a cli flag IIRC) and proot takes care of syscalls by definition.