>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
