Re: [OT] jar files - where - please explain
On 04/06/2015 17:31, Christopher Schultz wrote: snip/ We probably have a lot of places where we resolve filenames but I'm guessing we don't have a single utility method to do the work; Wrong :) probably just new File(new File(file).getCanonicalPath()) or something like that wherever it's needed. If we unified all those accesses in a single place, it would be easy to change these semantics for different environments. http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/web resources/AbstractFileResourceSet.java?view=annotate#l54 Nice work. So the code in there uses canonical paths, and when you canonicalize a symlink, you end up with the location of the real file, not the symlink, and everything goes boom at that point. Is my understanding correct? Correct. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] jar files - where - please explain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 6/4/15 3:15 AM, Mark Thomas wrote: On 03/06/2015 21:57, Christopher Schultz wrote: Mark, On 6/3/15 3:53 PM, Mark Thomas wrote: On 03/06/2015 20:48, Christopher Schultz wrote: snip/ I don't understand the underlying reasons why Tomcat treats symlinks specially... snip/ It is to do with case sensitivity on non case sensitive file systems. The check we have to add on Windows to stop things like JSP source disclosure by requesting /index.Jsp also blocks symlinks. Removing that check (and hence enabling symlinks) is safe on a case sensitive file system and unsafe on a non-case sensitive file system. Is that protection require something that can be detected by software, and then only applied when necessary? In theory, yes. In practise, given the security sensitivity of this I'd be very, very cautious about changing it. Agreed. There is probably some edge-case I'm not considering. ...but it *would* be nice to let symlinks work :) For instance, most UNIX filesystems have symlinks and case-sensitive filesystems, and these checks would not be necessary. Plus, users in those environments are quite used to using symlinks in place of real files. Windows users rarely use symbolic links, and have a case-sensitive filesystem, and these checks are certainly necessary. Prohibiting symbolic linking (by default) in this environment is probably okay. Mac OS X is a bit odd in that it's got all of the great things about a traditional UNIX filesystem except that it's got a better chance of being case-insensitive because HFS+ allows both semantics, but the default is unfortunately case-insensitive. In this environment, it's probably okay to prevent symbolic links unless he user forces them back on. The obvious way to check for case-sensitivity would be to create a file in the work directory with a certain name in mixed-case like TestFile.txt and then try to open it with an all-lowercase name (textfile.txt) and see if it exists. Then, we could enable or disable this kind of checking. Does anyone have any comments about something like that? We probably have a lot of places where we resolve filenames but I'm guessing we don't have a single utility method to do the work; Wrong :) probably just new File(new File(file).getCanonicalPath()) or something like that wherever it's needed. If we unified all those accesses in a single place, it would be easy to change these semantics for different environments. http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/web resources/AbstractFileResourceSet.java?view=annotate#l54 Nice work. So the code in there uses canonical paths, and when you canonicalize a symlink, you end up with the location of the real file, not the symlink, and everything goes boom at that point. Is my understanding correct? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVcH1nAAoJEBzwKT+lPKRYML8QAJJUxzgzTdrkvXHAF2W/OqKs yuca0UF0tGU72iPptVAF7Rsja1X+Bfi8V0SU7LWLtIP9VKaDTj1Vt2DNrCbArDPB lRMZlWNYBA/L/1HHh1wzk4CE1O5BcFQMUyKuzlvHFOhoN7LqSsiJoAPQLqrtM0rc 0VVtX51PBaB6QWzwwjTOUyJHto3CinPShekOhEUanSoSU5TO7wcpaqEwYK0YCZQx ATy0g7bg07RAfBzhZpgGmFzKDhIesNfD7RcCYYnktSr0LXIr8Onio+IQeyFjInGH bV5fSDaDmxlMvcWl8LrHtJqhw8B4qIKayXXtzeHongpgOKe6CsSLz8MaetWmb3QL 8S8IocN0XoLjegrWjmOyDNwRZo5/G9LpbFxBtMxY1uwW8pQ54Nk0hY5pAOcF8rGF B4gLxcAQy6L7Ml0ob26SdZufowy8QPgB8BGqHdH3jiUTiuoFoVX8QSXIEVnGqoy6 gxmvEjb6M5VkLkaib3F/4M+OSGg5n+ea45WqTUpLinfX37sC/HBL6bBrRRbFpAKk 30N8YOsblx4D2YbVe7M1HYvxcBOUoIBQxMSONg/VHArTgSdveA3BvhrHDOXY6WMf 6g/WTLNpHAaNBjlifRQCsCxr0wMAjGb8MFCxFDjDhR5Zz3VyWDCa0RWJ4UjfKIyj yRJd9Zxq45iPU0k7DBoD =2ME1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] jar files - where - please explain
From: Ray Holme [mailto:rayho...@yahoo.com.INVALID] Subject: Re: [OT] jar files - where - please explain I may be off base here, but IMHO Windoze does not support symbolic links Yes, you're off base. Windows symlinks have been available since Vista. GIYF. For example: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365680%28v=vs.85%29.aspx - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] jar files - where - please explain
For instance, most UNIX filesystems have symlinks and case-sensitive filesystems, and these checks would not be necessary. Plus, users in those environments are quite used to using symlinks in place of real files. Using Unix and Linux for a LONG time, love symlinks as they work across file systems and oh so much more. Windows users rarely use symbolic links, and have a case-sensitive filesystem, and these checks are certainly necessary. Prohibiting symbolic linking (by default) in this environment is probably okay. I may be off base here, but IMHO Windoze does not support symbolic links, or fork or ...It is more like a partial Unix (was built on the idea, but not fully formed). Mac OS X is a bit odd in that it's got all of the great things about a traditional UNIX filesystem except that it's got a better chance of being case-insensitive because HFS+ allows both semantics, but the default is unfortunately case-insensitive. In this environment, it's probably okay to prevent symbolic links unless he user forces them back on. Not a big user of OSX - not aware it supported case-insensitive. When I used it I treated it like Unix with case sensitive files and had NO problems. The obvious way to check for case-sensitivity would be to create a file in the work directory with a certain name in mixed-case like TestFile.txt and then try to open it with an all-lowercase name (textfile.txt) and see if it exists. Then, we could enable or disable this kind of checking. Sounds like the right approach. On Thursday, June 4, 2015 12:32 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 6/4/15 3:15 AM, Mark Thomas wrote: On 03/06/2015 21:57, Christopher Schultz wrote: Mark, On 6/3/15 3:53 PM, Mark Thomas wrote: On 03/06/2015 20:48, Christopher Schultz wrote: snip/ I don't understand the underlying reasons why Tomcat treats symlinks specially... snip/ It is to do with case sensitivity on non case sensitive file systems. The check we have to add on Windows to stop things like JSP source disclosure by requesting /index.Jsp also blocks symlinks. Removing that check (and hence enabling symlinks) is safe on a case sensitive file system and unsafe on a non-case sensitive file system. Is that protection require something that can be detected by software, and then only applied when necessary? In theory, yes. In practise, given the security sensitivity of this I'd be very, very cautious about changing it. Agreed. There is probably some edge-case I'm not considering. ...but it *would* be nice to let symlinks work :) For instance, most UNIX filesystems have symlinks and case-sensitive filesystems, and these checks would not be necessary. Plus, users in those environments are quite used to using symlinks in place of real files. Windows users rarely use symbolic links, and have a case-sensitive filesystem, and these checks are certainly necessary. Prohibiting symbolic linking (by default) in this environment is probably okay. Mac OS X is a bit odd in that it's got all of the great things about a traditional UNIX filesystem except that it's got a better chance of being case-insensitive because HFS+ allows both semantics, but the default is unfortunately case-insensitive. In this environment, it's probably okay to prevent symbolic links unless he user forces them back on. The obvious way to check for case-sensitivity would be to create a file in the work directory with a certain name in mixed-case like TestFile.txt and then try to open it with an all-lowercase name (textfile.txt) and see if it exists. Then, we could enable or disable this kind of checking. Does anyone have any comments about something like that? We probably have a lot of places where we resolve filenames but I'm guessing we don't have a single utility method to do the work; Wrong :) probably just new File(new File(file).getCanonicalPath()) or something like that wherever it's needed. If we unified all those accesses in a single place, it would be easy to change these semantics for different environments. http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/web resources/AbstractFileResourceSet.java?view=annotate#l54 Nice work. So the code in there uses canonical paths, and when you canonicalize a symlink, you end up with the location of the real file, not the symlink, and everything goes boom at that point. Is my understanding correct? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVcH1nAAoJEBzwKT+lPKRYML8QAJJUxzgzTdrkvXHAF2W/OqKs yuca0UF0tGU72iPptVAF7Rsja1X+Bfi8V0SU7LWLtIP9VKaDTj1Vt2DNrCbArDPB lRMZlWNYBA/L/1HHh1wzk4CE1O5BcFQMUyKuzlvHFOhoN7LqSsiJoAPQLqrtM0rc 0VVtX51PBaB6QWzwwjTOUyJHto3CinPShekOhEUanSoSU5TO7wcpaqEwYK0YCZQx ATy0g7bg07RAfBzhZpgGmFzKDhIesNfD7RcCYYnktSr0LXIr8Onio+IQeyFjInGH
Re: [OT] jar files - where - please explain
On 03/06/2015 21:57, Christopher Schultz wrote: Mark, On 6/3/15 3:53 PM, Mark Thomas wrote: On 03/06/2015 20:48, Christopher Schultz wrote: snip/ I don't understand the underlying reasons why Tomcat treats symlinks specially... snip/ It is to do with case sensitivity on non case sensitive file systems. The check we have to add on Windows to stop things like JSP source disclosure by requesting /index.Jsp also blocks symlinks. Removing that check (and hence enabling symlinks) is safe on a case sensitive file system and unsafe on a non-case sensitive file system. Is that protection require something that can be detected by software, and then only applied when necessary? In theory, yes. In practise, given the security sensitivity of this I'd be very, very cautious about changing it. For instance, most UNIX filesystems have symlinks and case-sensitive filesystems, and these checks would not be necessary. Plus, users in those environments are quite used to using symlinks in place of real files. Windows users rarely use symbolic links, and have a case-sensitive filesystem, and these checks are certainly necessary. Prohibiting symbolic linking (by default) in this environment is probably okay. Mac OS X is a bit odd in that it's got all of the great things about a traditional UNIX filesystem except that it's got a better chance of being case-insensitive because HFS+ allows both semantics, but the default is unfortunately case-insensitive. In this environment, it's probably okay to prevent symbolic links unless he user forces them back on. The obvious way to check for case-sensitivity would be to create a file in the work directory with a certain name in mixed-case like TestFile.txt and then try to open it with an all-lowercase name (textfile.txt) and see if it exists. Then, we could enable or disable this kind of checking. Does anyone have any comments about something like that? We probably have a lot of places where we resolve filenames but I'm guessing we don't have a single utility method to do the work; Wrong :) probably just new File(new File(file).getCanonicalPath()) or something like that wherever it's needed. If we unified all those accesses in a single place, it would be easy to change these semantics for different environments. http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java?view=annotate#l54 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] jar files - where - please explain
Inside the WAR or having the WAR as a symlnk?
OK, I did a test and YES inside a WAR file
${CATALINA_HOME}/webapps/Application/WEB-INF/lib/*.jarfiles ARE expanded if
they are symbolic links to real files. (My bad for not testing before).Now I am
really in trouble. I have an application which has a
${CATALINA_HOME}/webapps/Application/photosdirectory which is a symbolic link
with the following line in the
${CATALINA_HOME}/conf/Catalina/localhost/Application.xmlfile:
aliases=/photos=/opt/web_bigDirs/Applicationi_photos - I NEVER wanted this
link expanded!!!The idea is to have multiple deployment places (hoping someday
when testing done), each having their own photos on file and never deploy my
own test photos. I was assuming this would work. I tested and double DARN, jar
cf expands the link pulling in all the sub files - this totally frustrates my
intention. I wanted a symbolic link there for Unix based machines and just an
empty directory for Microsoft OS(s). Perhaps if I remove my symbolic link the
aliases parameter will work anyway. I will have to try that when I get a
chance. I certainly don't want to distribute the contents of this directory
in a war file (it could be HUGE).
On Thursday, June 4, 2015 3:15 AM, Mark Thomas ma...@apache.org wrote:
On 03/06/2015 21:57, Christopher Schultz wrote:
Mark,
On 6/3/15 3:53 PM, Mark Thomas wrote:
On 03/06/2015 20:48, Christopher Schultz wrote:
snip/
I don't understand the underlying reasons why Tomcat treats
symlinks specially...
snip/
It is to do with case sensitivity on non case sensitive file
systems. The check we have to add on Windows to stop things like
JSP source disclosure by requesting /index.Jsp also blocks
symlinks.
Removing that check (and hence enabling symlinks) is safe on a
case sensitive file system and unsafe on a non-case sensitive file
system.
Is that protection require something that can be detected by software,
and then only applied when necessary?
In theory, yes.
In practise, given the security sensitivity of this I'd be very, very
cautious about changing it.
For instance, most UNIX filesystems have symlinks and case-sensitive
filesystems, and these checks would not be necessary. Plus, users in
those environments are quite used to using symlinks in place of real
files.
Windows users rarely use symbolic links, and have a case-sensitive
filesystem, and these checks are certainly necessary. Prohibiting
symbolic linking (by default) in this environment is probably okay.
Mac OS X is a bit odd in that it's got all of the great things about a
traditional UNIX filesystem except that it's got a better chance of
being case-insensitive because HFS+ allows both semantics, but the
default is unfortunately case-insensitive. In this environment, it's
probably okay to prevent symbolic links unless he user forces them
back on.
The obvious way to check for case-sensitivity would be to create a
file in the work directory with a certain name in mixed-case like
TestFile.txt and then try to open it with an all-lowercase name
(textfile.txt) and see if it exists. Then, we could enable or
disable this kind of checking.
Does anyone have any comments about something like that?
We probably have a lot of places where we resolve filenames but I'm
guessing we don't have a single utility method to do the work;
Wrong :)
probably just new File(new File(file).getCanonicalPath()) or something
like that wherever it's needed. If we unified all those accesses in a
single place, it would be easy to change these semantics for different
environments.
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java?view=annotate#l54
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] jar files - where - please explain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 6/3/15 3:53 PM, Mark Thomas wrote: On 03/06/2015 20:48, Christopher Schultz wrote: snip/ I don't understand the underlying reasons why Tomcat treats symlinks specially... snip/ It is to do with case sensitivity on non case sensitive file systems. The check we have to add on Windows to stop things like JSP source disclosure by requesting /index.Jsp also blocks symlinks. Removing that check (and hence enabling symlinks) is safe on a case sensitive file system and unsafe on a non-case sensitive file system. Is that protection require something that can be detected by software, and then only applied when necessary? For instance, most UNIX filesystems have symlinks and case-sensitive filesystems, and these checks would not be necessary. Plus, users in those environments are quite used to using symlinks in place of real files. Windows users rarely use symbolic links, and have a case-sensitive filesystem, and these checks are certainly necessary. Prohibiting symbolic linking (by default) in this environment is probably okay. Mac OS X is a bit odd in that it's got all of the great things about a traditional UNIX filesystem except that it's got a better chance of being case-insensitive because HFS+ allows both semantics, but the default is unfortunately case-insensitive. In this environment, it's probably okay to prevent symbolic links unless he user forces them back on. The obvious way to check for case-sensitivity would be to create a file in the work directory with a certain name in mixed-case like TestFile.txt and then try to open it with an all-lowercase name (textfile.txt) and see if it exists. Then, we could enable or disable this kind of checking. Does anyone have any comments about something like that? We probably have a lot of places where we resolve filenames but I'm guessing we don't have a single utility method to do the work; probably just new File(new File(file).getCanonicalPath()) or something like that wherever it's needed. If we unified all those accesses in a single place, it would be easy to change these semantics for different environments. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVb2o/AAoJEBzwKT+lPKRY6REQALYt4gPup33oDcMo6Rp6kW7P 3OFP4M3fGcYZ4tu3aFI+wlGhp/ikBwNUMCFoLrtITIbNJ6EDl4KZOUUdUUjldjd0 uFHC8AQcKoU62Z36vUYknmTmtD39/ibQJ6orv6/L6sN5UZE5fYTIwkw/qN1VEwCk YCLGK+oJl3daYEuo4md4IVeGPOWC9COQ5VPY/OVfHk4m/cfRWCdTwjsFcs256wKj kgTBWiZaclr8zVaTCUWVdyUAahdzJ7k90Sp1anZpJUm1XKOC8ySc3z5ygvep1JZD 3IBB49QZXYwQuVj43t96QzxcRmBUf+KeaZ7QLfi/+cIonhy5uLoMxzON/njZtvIC TTQhPJjE53wIcqHttI7BgiwqvgmuSJHAhlFc39sHWQFqqgxDBudoGngfK9BITd/Y oxg+at2IZaTfM9JM7kirt/oppUkif1tELaU44iJFT4vnVTLRZ3AvxBOG6mOWoWkx 5+pIzoOlOmQdhZUxQS3ziX+QDt3wz8vb6Y0EMuUCqc3wEHLeLkoeTguPIE2YQopN zh5y1eZ9mlGppXoRxHrnvtRPtxsXTQnEakyMGGcY2oQOmsl5TLvrJfMLmeoM5UIv sGdoy6kg5fuxWQRxIj2JcOgmgmS5wTCyV4K0dYm4z0NLp08THivEMVaVgBkEplZL 9kVcfiuD4aNCn5HXzCNd =3XAR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
