On Thu, 16 Sep 2021 10:14:47 GMT, Julia Boes <jb...@openjdk.org> wrote:
>> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose main method is run when the above >> command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given >> directory, similar to existing alternatives on other platforms and >> convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and >> customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request incrementally with one additional > commit since the last revision: > > correct path handling > _Mailing list message from [Jaikiran Pai](mailto:jai.forums2...@gmail.com) on > [core-libs-dev](mailto:core-libs-...@mail.openjdk.java.net):_ > > Hello Bernd, > > On 17/09/21 3:37 am, Bernd Eckenfels wrote: > > > I also wonder if it makes sense to either only serve files with public > > permissions, or at least Filter some critical files like .ssh/* and *.jks. > > FWIW - From what I can see in the proposed implementation as well as the > JEP text, hidden files and symbolic links aren't served. So it should > prevent listing/serving .ssh/ directory. > > -Jaikiran File system access is checked for the root directory and the requested resource (summarized in the CSR [1]). You're right that hidden files, symbolic links, and not-readable files are not served. Looking at the example of `.ssh/*`, I realize we missed the case where a component of the request path is hidden (or not readable), rather than the requested resource itself. For example, if `/` is the server's root directory, a request of `http://host:port/.ssl/config` would be successful because config is not hidden. A request of `http://host:port/.ssl` would get a 404. I'll update this to apply the isHidden and isReadable checks to the requested resource *as well as* all components of its path. No further group/owner/other permissions are checked - that's a can of worms we didn't want to get in to, given that this server is really not appropriate for serving file hierarchies that contain sensitive information. Again, it's a simple tool for development and testing purposes only. [1] https://bugs.openjdk.java.net/browse/JDK-8272571 ------------- PR: https://git.openjdk.java.net/jdk/pull/5505
