You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2015/06/03 22:57:35 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jar files - where - please explain
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ray,
On 6/4/15 8:01 AM, Ray Holme wrote:
>> 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.
What? The JAR utility does not support symlinks, so your JAR tool is
likely putting the whole file into the WAR archive.
Now, ZIP files *do* support symlinks, but I'll bet that Java will
fall-over if you try to open a ZIP file and it encounters a symlink in
there.
> (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
Pointing where?
> with the following line in the
> ${CATALINA_HOME}/conf/Catalina/localhost/Application.xml file:
> aliases="/photos=/opt/web_bigDirs/Applicationi_photos" - I NEVER
> wanted this link expanded!!!
Tomcat doesn't expand anything. If you have a WAR file with an "alias"
configured in it, it will just access the aliased directory directly.
> 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.
Can you explain this in a little more detail? Remember that nobody
here has any idea what your application does, or what you expect to
happen.
> I was assuming this would work.
"Trust But Verify"?
> 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.
The aliases setting is completely independent from any symlink
business you've got going on.
> 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).
I would just use the aliases setting and remove the symlink entirely.
The entire purpose of "aliases" is to allow you to have the effect of
symlinks, but do it in a safe way (that doesn't delete all your
symlinked files when you undeploy the web application, for instance).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVcH7bAAoJEBzwKT+lPKRYwKEP/0nrcgRPykFIioBnPhPEUv1J
PeOpUpKrsSCHBjgIq691Bo1nZTWkdCAiplC/rBv7VRw3iW6d1oGkdQcK3xV66wiS
xlU2RwGfVYjau0Vbn/gTi4IimAMYYuzLWwYUOv9c9zNCcsctJlCVLksO9XDTHOdU
wl3D54WENVuAxFxP0P9iIoT1UEu0myAQHtcO0ez0uvdzt1DkaFR+EkJHDWcBPjPB
cqvHXOYHzR6Ixv4Z3t+8DprmPHgIHQxjPlt4OhEIgGFqE0q1oDA6VKjdDcRETdQB
Q0v6eynBC43w7Ac61R6KU6zNXxpxTWL+8+xZ9dqAy8zlJmsDqLUXt8SkDGc9mkJR
lcELbmfKttsHIgoVydyBjS8WyvpAYYkS8MLj/ntpb1w7lWuKHV6tHkcyX2pSfOEG
g1sMUU8P4/rCrFk69/1GJkP9DUL1nfIskGybQ1cTPuBs5m1tPIgVVhSf8swOLdYl
6tkG+9+H8x8ICW/kuggSmiD8aKpl3+NBmfxRhzUJBNSDUDIsyGCp4vT2usAExyu4
SEaC5XlB18uNvIoZrDWx7naodWiMRIgTCno0cJyNgq+NpxlRJ7NbOHpa8xzwK0gV
RG1vzP6jvSxIHioIk/W+R7+hiWU2DyzePAIhVsCTcvf96CmMuYtub3x+WYF5vEnM
ZCBcvR4CU2ba0oIZQcXB
=N8tQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] jar files - where - please explain
Posted by Ray Holme <ra...@yahoo.com.INVALID>.
>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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] jar files - where - please explain
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Ray Holme [mailto:rayholme@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] jar files - where - please explain
Posted by Ray Holme <ra...@yahoo.com.INVALID>.
>> 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
bV5fSDaDmxlMvcWl8LrHtJqhw8B4qIKayXXtzeHongpgOKe6CsSLz8MaetWmb3QL
8S8IocN0XoLjegrWjmOyDNwRZo5/G9LpbFxBtMxY1uwW8pQ54Nk0hY5pAOcF8rGF
B4gLxcAQy6L7Ml0ob26SdZufowy8QPgB8BGqHdH3jiUTiuoFoVX8QSXIEVnGqoy6
gxmvEjb6M5VkLkaib3F/4M+OSGg5n+ea45WqTUpLinfX37sC/HBL6bBrRRbFpAKk
30N8YOsblx4D2YbVe7M1HYvxcBOUoIBQxMSONg/VHArTgSdveA3BvhrHDOXY6WMf
6g/WTLNpHAaNBjlifRQCsCxr0wMAjGb8MFCxFDjDhR5Zz3VyWDCa0RWJ4UjfKIyj
yRJd9Zxq45iPU0k7DBoD
=2ME1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] jar files - where - please explain
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] jar files - where - please explain
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] jar files - where - please explain
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org