>>>>> 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