>> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
