Flag or env variable to control whether to load native Posix implementation or JavaPosix implementation

[mahesh1996]

By default Jython loads the native implementation of Posix here https://github.com/jython/jython/blob/v2.7.3/src/org/python/modules/posix/PosixModule.java#L85C1-L85C1

Instead of passing true always, shouldn't be there a flag or some env variable to control this behaviour if someone always wants to load JavaPosix.

One usecase is, we want to make sure all of these method calls go through Java's Security Manager. If native Posix implementation is used then many of the method calls are fulfilled natively without using Java APIs and thus skipping Java's Security Manager.

[jeff5]

This seems a reasonable idea. My first thought is that we'd want to test it in both modes, somehow in the regression tests and CI, but since both modes are there already, we should have been already. It might even make that easier.

Jython likes to control that kind of thing through its registry, rather than environment variables. The registry includes the Java system properties (which can be supplied on the command line).

[robertpatrick]

@mahesh1996 @jeff5 The Java SecurityManager is deprecated starting in JDK17 and the plan is to remove it eventually. Probably not a great idea to build more features around it.

[jeff5]

@robertpatrick You sent me on an interesting reading diversion, thanks. It is cited as "one use case".

Ideally I would have only a pure Java implementation. My impression is that Java's handling of file systems has matured since we took this route. That doesn't of course mean that the native Posix code has taken advantage of that. I remain broadly positive if it's easy.

[robertpatrick]

@jeff5 I would be concerned about a "pure Java implementation" since our code is currently relying on importing both ntpath and posixpath to support our SSH-based remote access.

In general, Java loads the file system logic based on the execution platform; for example, when running on Linux the path c:\Temp\foo.yaml is not considered an absolute path by java.io.File.isAbsolute() or java.nio.file.Path.isAbsolute(). I recently moved our code away from using these Java classes to using ntpath.isabs() explicitly when the remote machine is running Windows so that we get the right answer.

[jeff5]

our code is currently relying on importing both ntpath and posixpath

I remember misunderstanding the need for both of these to work whatever the platform early in my Jython adventures and having to unpick it. "Right" answer here means conventional Python answer (to a normalisation or enquiry) I suppose. Granted these may differ from Java's answers to a similar sounding question. But if it is computable without being on the platform in question, then we can do that in any language we like. And if it requires looking in the file system, then we're in the territory of the os module, so not cross-platform in the way that concerns your use case.

My conjecture/hope is that Java now provides enough of the os module for us to be content. A lot of os is optional because it doesn't work cross-platform, even in CPython.

[robertpatrick]

I could re-implement join, isabs, realpath, basename, etc in Java for each platform. The point is that I cannot rely on the Java implementation for either POSIX or Windows because I have yet to find a way to control which implementation is loaded, much less load both into the same process regardless of the underlying OS. For many situations, people do not need that level of control. When accessing remote file systems via SSH, we do. Our current solution is working without me needing to reimplement anything. Whatever you do, I would ask that you do not break what is already in place and working.