I know mock does not really claim to be "secure", but it's worth at least keeping track of these sorts of issues for two reasons: - To demonstrate criteria by which an actually secure build system should be judged - It's worth fixing these for reliabilty reasons # mock -r epel-7-x86_64 --init --install strace --uniqueext=/../../../tmp/foo will create a chroot outside of /var/lib/mock in /var/tmp/foo, and I can't see anything stopping one from just overwriting the host /.
I am not sure if this should be addressed. If your user is in 'mock' group, then you can root access anyway. And if you provide incorrect path... well we provide gun, and you are shooting. If you want to shoot into your leg... And btw, if you have selinux enabled, it should stop you from overwriting /.
(In reply to Miroslav Suchý from comment #1) > I am not sure if this should be addressed. If your user is in 'mock' group, > then you can root access anyway. Right. But given that, I feel the `mock` group is a historical mistake, as there's an implication that it provides security where it doesn't. If a program is effectively equivalent to a root shell, it would have been beetter to require use of `sudo`. (One could find the uid to chown result files via `SUDO_UID` etc.) It would drop a vast amount of complexity from mock. I'm not arguing for making this change now though, it probably isn't worth doing. For reference I am the developer of https://git.gnome.org/browse/linux-user-chroot which I do believe is secure, and that's the specific program that I'm comparing vs mock.