Mail Archives: cygwin/2008/12/03/07:08:04
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/
- Raw text -