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.
For those that don’t know, you shouldn’t blindly let programs have access to tmp. They can get access to sockets and stuff. If you’re running with systemd there’s a private tmp option for this reason.
It’s always best to sandbox programs when you can. Linux has been making this much easier but it’s still non trivial
"`unshare -m` and then bind-mounting a private /tmp at /tmp/systemd-private-/ does the same thing"
As an intermediate level user and sysadmin, this kind of thing underscores the good work systemd is doing making it easy to get sane and safe defaults for things otherwise fiddly enough that many normal people wouldn't bother.
And in a config file format so we don't have to add things like renice, respawn, chroot, and namespaces to a locally forked Sys-V unit script for just one distro.
Yeah that helps but it depends on the permission of the socket. You can make it harder to guess by changing control path.
Here’s an article that talks about tmp[0]. But I mean if you wanted to be really secure you could use systemd nspawn and put each user into their own container[1]
Please don't use zero-based footnote citations, people will assume 1 is the first one (because that is the standard in like, all of literature) and muscle-memory click the first link when reading and have to then figure out that you are doing a non-standard thing.
Language is not defined by a dictionary or MLA guides or whatever. Language is defined by culture. Go ask any linguist if your in doubt. They’ll gladly talk your ear off about how language evolves and cliques form and how there’s in and out language which people can often identify others in their “tribe” by. Like respect for any culture, don’t come in and try to tell people what’s right or wrong. At least not until you can speak the language first.
We use [0] because it’s how you index an array.
More general to internet culture there’s also OP = original poster and we refer to comments above us like family relationships. Parent (you’re this comments parent), GP (the grandparent, one who used the [0] that triggered you), GGP, G..GP, there’s siblings/sister (everyone who replied to you) and so on. Generally people don’t say cousins, aunts, dust removed and so on but you might see it). RTFM = read the fucking Manual (RTFA for article). And many others.
Funnily enough, that's exactly the debate (whether or not natural numbers start at 0 or 1). There is no universally right or wrong answer, is comp sci nerds just tend to like 0 :p.
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