[tor-bugs] #32476 [Applications/Tor Browser]: Support Launching TorService Using JNI
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Nov 26 12:49:13 UTC 2019
#32476: Support Launching TorService Using JNI
-------------------------------------------------+-------------------------
Reporter: sisbell | Owner: tbb-
| team
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: Android, tbb-mobile, | Actual Points:
TorBrowserTeam201911 |
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by eighthave):
> Are the native methods only supported on Android or all platforms? I'm
asking this since TOPL is desktop/mobile so this good info to have for
planning whether we can continue support across the board.
The JNI code should work on any Java or Android version. I tested them on
Java only in the beginning, so I don't know the status there. But any
breakage there is most likely trivial. Is Desktop TBB using TOPL?
> 1) I still see that we need to wait for the control port creation file.
This is what was causing some earlier problems. Will this be fixed with
the JNI code in the future or does the problem lie in the tor code itself?
The best solution for this is to create a pipe/stdin/stdout interface for
the ControlPort. Then Java code can interact directly with it, without
any kind of socket. This current solution should be better than before
because it is based on a UNIX domain socket rather than a TCP socket. So
it uses the Linux inotify API, which is quite reliable, to get an event
when the socket file is created.
> 2) Authentication appears to just be default, with no cookies. If we add
cookie base auth, I think we would also need to wait for that file
creation as well.
>
> I bring up (1) and (2) specifically since these were pain points in the
past and don't seem to be mitigated in the current code.
With a pipe/stdin/stdout interface for the ControlPort, cookie auth is not
needed. On Android, creating the UNIX socket file within the app's
private file dirs should eliminate the need for the cookie auth, based on
standard Android file permissions. Setting the permissions on the socket
file itself further ensures that. I have the cookie auth working as well,
with an inotify wait, if that's needed. But that'll likely be more
brittle, given more moving parts.
The change here is switching from TCP socket to UNIX domain socket on the
filesystem. That will eliminate a lot of pain points:
* no more TCP port conflicts
* access control via standard Android file/dir permissions
* detect controlport creation using Linux inotify
> 3) The JNI code will lock down the implementation class as TorService,
which is also the Android service class. I think it would be better to
move the JNI interaction to a different class, which is then called by
TorService class. This will make it more reusable by third-parties.
There is nothing about ''src/feature/api/org_torproject_jni_TorService.c''
that locks it to Android. JNI files do not normally declare a Java class,
they implement methods for a class declared in a ''.java'' file. ''tor-
android-binary/src/main/java/org/torproject/jni/TorService.java'' is the
Android setup. There should be a separate ''TorService.java'' for Java.
There isn't enough in the ''TorService.java'' that is shareable between
Android and Java. Trying to make a shared super class will make the code
really confusing and hard to follow, while only sharing some trivial bits
of code.
> 4) We are using file descriptor for the control port with the JNI
version. This is good. (It does mean this only support *nix based
systems).
The UNIX domain socket code in
`Java_org_torproject_jni_TorService_prepareFileDescriptor()` might only be
relevant on Android, but it probably works on Java. I think there are
probably better ways to do this on Java.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32476#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list