Julio Emanuel wrote: > Aha! So this is the tiny bit that was missing! What you are saying is > that the Cygwin DLL does not honor the chroot if the path is in WIN32 > format? But why is that? It shouldn't honor the chroot all the time? > I mean, this sounds like the "right thing to do"(tm), if Cygwin is > supposed to fully support chroot environments...
I haven't verified that this is the case, but I suspect that it is. The general philosophy of most of the path handling code is that Win32 paths bypass all Cygwin logic entirely. There are still lots of people that try to use Win32 paths with Cygwin tools despite the fact that it's not supposed to be how things are done (and discouraged.) As to whether it should try to special-case this situation and disallow the use of Win32 paths if a chroot is in effect, I'm not sure if it makes sense. As others in the thread have already said, the chroot feature is meant to be "necessary but not sufficient", if you will. I.e. it's a convenience, not an enforecement. Most of the time when you encounter a program that's been put in a chroot jail the reasoning is so that if there is some kind of exploitable vulnerability in that program an attacker cannot gain access to the rest of the system outside of the jail. In this scenario the chroot provided by Cygwin provides zero protection, because if the attacker can run exploit code then can just call directly to the Win32 APIs and bypass Cygwin entirely. No amount of protection in the DLL will ever change this basic fact, so just seems to me like you'd be furthering the illusion of security by trying to add more checks. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
