[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