chroot, mount --bind, and binfmt_misc without privilege/setup for Linux, https://proot-me.github.io
Here it is with su:
admin1@hpcadmin:/tmp/tmp.CCJUwj1ek1$ /nix/store/cmfg6pb6v18f5g1wnskl18dzpccmlwy0-util-linux-2.38.1-bin/bin/unshare -r --map-auto -pfn --mount-proc=/proc /nix/store/3z8i6cz460k36xm7qgvf48ijhi027gjy-proot-5.3.1/bin/proot -b etc/passwd:/etc/passwd -b log:/var/log bash
root@hpcadmin:/tmp/tmp.CCJUwj1ek1# ls -alh /etc/passwd
-rw-r--r-- 1 root root 62 okt 25 22:41 /etc/passwd
root@hpcadmin:/tmp/tmp.CCJUwj1ek1# id
uid=0(root) gid=0(root) groups=0(root),65534(nogroup)
root@hpcadmin:/tmp/tmp.CCJUwj1ek1# su test
$ id
uid=1000 gid=100(users) groups=100(users)
$ ls -alh /etc | grep passwd
ls: cannot access '/etc/passwd': Permission denied
-????????? ? ? ? ? ? passwd
Ok I forgot to try with -v
The translate call seems to happen
proot info: vpid 9: got event 7057f
proot info: vpid 9: sysenter start: statx(0xffffff9c, 0x7ffd2546a601, 0x100, 0x25e, 0x7ffd25469c90, 0xb) = 0xffffffffffffffda [0x7ffd25469c88, 0]
proot info: vpid 9: translate("/" + "/etc/passwd")
proot info: vpid 9: -> "/tmp/tmp.CCJUwj1ek1/etc/passwd"
proot info: vpid 9: sysenter end: statx(0xffffff9c, 0x7ffd25469be8, 0x100, 0x25e, 0x7ffd25469c90, 0xb) = 0xffffffffffffffda [0x7ffd25469c88, 0]
proot info: vpid 9: restarted using 7, signal 0
its probably failing to read /tmp/tmp.CCJUwj1ek1/etc/passwd because an intermediate directory somewhere doesnt allow reading for the new uid
oxr463: yeah that was the problem. the tmp dir wasnt readable from the mapped test user uid
so many pieces to all this stuff x)
Why use PRoot if you already have root?
I'm curious about the use case
I realized that about half an hour ago after taking a shower :P
I used to have issues figuring out bind mounts but I might be able to do it now
alternatively, proot is easier to prototype with
That's good
I think I kind of sort of barely figured out how to use unshare to do the rootless stuff at this point
I seriously did not expect this to be it
though I guess its possible you are just merging it and then building on it haha
I did see something about seccomp mode being supported on that given proot
so in that case is ptrace not used?
hm, not sure what happened there then though I didnt read the output very carefully
specifically for stracing though you cant ptrace a ptrace so that shouldnt work
hmmmmm
the other possibility is that strace is using seccomp for tracing, unless i completely misunderstood everything and this isnt even a thing
--seccomp-bpf
Try to enable use of seccomp-bpf (see seccomp(2)) to have ptrace(2)-stops only when system calls that are being traced occur in the traced processes. This option has no effect unless -f/--follow-forks is also
specified. --seccomp-bpf is also not applicable to processes attached using -p/--attach option. An attempt to enable system calls filtering using seccomp-bpf may fail for various reasons, e.g. there are too many
system calls to filter, the seccomp API is not available, or strace itself is being traced. In cases when seccomp-bpf filter setup failed, strace proceeds as usual and stops traced processes on every system call.
I don't 100% understand what this is sayng
it only fails to ptrace processes that are already being ptraced but works otherwise?
well that wouldnt help much for proot since its ptracing everything (?)
1 reply
(wouldnt proot have to be ptracing all children to work?)
But if a program doesn't allow ptrace then it won't work
So you can use gdb or strace on PRoot itself... but depends on what runs inside the PRoot if you can ptrace it
well half my problem was I kept messing up a file name, so I did end up solving it with the fake mounts, but I was more wondering if (I really should just check with -v) internal mount --bind could /is be caught and emulated (if that makes sense)
1 reply
oxr463: another suggestion: allow specifying a file to output -v output to