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: [email protected]
For additional commands, e-mail: [email protected]
