>> Here is a patch that implements fexecve(2) for review: > This strikes me as profoundly dangerous. Among other things, it > means you can't allow any program running in a chroot to receive > unix-domain messages any more since they might get passed a file > descriptor to code they should not be able to execute.
Let me phrase that a bit differently: This gives you the ability to give a chrooted process access to outside-chroot executables in a controlled way. I don't see this as fundamentally any different from using SCM_RIGHTS to give a chrooted executable access to a data file it can't name. Not all executables have their execute bits set, after all; I don't see any fundamental difference between passing a fd to fexecve() and passing a fd to a script for which the chrooted executable happens to contain an interpreter. After all, to do anything with this requires the cooperation of the chrooted process's executable, and if it wants to, heck, it could even include a whole virtual machine and thus "execute" the executable without ever needing to do anything exec()-family. So, unless I'm missing something, I don't see how this breaks chroots in any way they aren't already broken. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
