jsr369-experts@servlet-spec.java.net

[jsr369-experts] [SERVLET_SPEC-172-Part.write] PROPOSAL

From: Edward Burns <edward.burns_at_oracle.com>
Date: Wed, 29 Mar 2017 01:18:41 -0700

>>>>> On Fri, 24 Mar 2017 10:13:34 +0000, Mark Thomas <markt_at_apache.org> said:

EB> I am hesitant to tighten the set of allowable values to Part.write()
EB> such that things that used to work cease working, with the exception
EB> of using "../" to escape one web app and write into the space of
EB> another.

MT> That assumes that the location in the MultipartConfig is inside the web
MT> application. That is rarely the case.

MT> I don't see any need for this API to limit where a web application can
MT> write. Web apps can access any part of the file system via the standard
MT> Java API so I see no point in limiting it here.

MT> The SecurityManager is the correct way to limit where web applications
MT> can write.

Greg, what say you to this?

The performance implications of running under a SecurityManager are
significant, but your observation that any code that might be calling
Part.write() can already write anywhere is very apt.

[...]

MT> My suggestion, starting from Tomcat's current Javadoc and taking account
MT> Greg's feedback is:

MT> @param fileName The location into which the uploaded part should
MT> be stored. file names and relative paths are
MT> relative to {_at_link
MT> javax.servlet.MultipartConfigElement#getLocation()}.
MT> Absolute paths are used as provided.
MT> Note: that this is a system dependent string and URI
MT> notation may not be acceptable on all systems. For
MT> portability, this string should be generated with the
MT> File or Path APIs.

Mark, thanks for your concise suggestion. In the spirit of compromise,
I vote to accept Mark's proposal here.

ACTION: voice any dissent by close of business Monday 3 April 2017.

Thanks,

Ed

-- 
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 17 business days until planned start of Servlet 4.0 Public Review