- How to install glibc linux how to#
- How to install glibc linux software#
- How to install glibc linux code#
You'll notice that something's not right.
How to install glibc linux software#
try to launch some complex software this way, specifically software that launches another software. It launches your glibc program and, like Steve Jobs used to say, it just works.īut. (Note that you should also bind-mount /etc and /var when you use xbps utilities such as xbps-install.)Īs we don't need root anymore, drop it: uid_t uid = getuid() Īnd finally, launch our program: execvp(argv, ( char * const *)argv+ 1) Then bind-mount your glibc container's (which, I'll assume for simplicity, resides in /glibc) /usr (this won't be visible outside the new namespace): mount( "/glibc/usr", "/usr", NULL, MS_BIND|MS_REC, NULL) Use unshare(2) for that: unshare(CLONE_NEWNS) So let's get straight to the task.įirst, we need to create new mount namespace, or in other words "unshare" the current namespace of the process and change to the private copy of this namespace.
How to install glibc linux code#
I'll omit all boring stuff like arguments processing logic, user input validation and so on, if you're interested in that, read the code of the final program. Where voidnsrun is the name of the program we're going to write, glibc_program is the name of our glibc program and -arguments. The program is supposed to be used like this: $ voidnsrun glibc_program -arguments. In real programs you need to check return values of almost all function calls and do a lot of other stuff. We'll do the latter, but remember that setuid in general is a security risk and one have to be very careful when writing setuid programs.ĭisclaimer: all code in this article is only to demonstrate the ideas.
To be able to use them, you either need to be root or the binary must be owned by root and have setuid bit.
How to install glibc linux how to#
It's possible to use user namespaces instead, but they break setuid binaries (or maybe I just don't know how to prepare them properly), so I decided to stick to classic old mount namespaces. To use mount namespaces, one needs root privileges. The code in the blog post wasn't anywhere "production-ready", though, so I decided to write a new ready-to-use program based on this idea. The mounts will be invisible for the rest of the system. The idea is simple: create new mount namespace, bind-mount the /usr from the glibc container at your real /usr, thus substituting your real /usr with "fake" /usr from the glibc container where all binaries and libraries are glibc-linked, and launch your glibc program inside this mount namespace. Then I found this blog post discussing another way, using mount_namespaces(7) as an elegant alternative to chroot. Using chroot seemed too primitive and inconvenient, even if I wrote scripts to automate all steps, so I kept looking. Void documentation suggests to perform a glibc base system installation via base-bootstrap to a separate directory (I'll be referring to it as the glibc container), chroot to it and run glibc binaries from within this chroot.
0 kommentar(er)
