This repository has been archived by the owner on May 6, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 94
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Don't use os.NewFile to create the TUN writer (#63)
* Don't use os.NewFile to create the TUN writer os.NewFile takes ownership of the file descriptor, and adds a finalizer that closes the file descriptor when the file is garbage-collected. This violates Outline's interface contract (caller retains ownership of the TUN device), and could cause a problem if the file descriptor is still being used See Jigsaw-Code/Intra#285 * Return to MakeTunFile, but add a call to Dup * Remove refactoring changes * Close the tunWriter and update comments
- Loading branch information
Benjamin M. Schwartz
authored
Sep 21, 2020
1 parent
6ab67d2
commit 9b609c0
Showing
7 changed files
with
20 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
9b609c0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would an equivalent change to this be to send
fd
returned byParcelFileDescriptor#detachFd
instead ofParcelFileDescriptor#getFd
from the Java land totunnel.MakeTunFile
but not useunix.Dup
? Since, in this case, Java gives up ownership of thefd
, the golang finalizer foros.File
is free to close thefd
whenever it sees fit (unlesstunnel.Disconnect
closes it beforehand, that is). Thoughts?Refs:
https://github.com/google/vpn-reverse-tether/blob/304749e5c11d0466cfeef3220c91e91401c53167/src/vpntether/TetherService.java#L126
https://github.com/google/vpn-reverse-tether/blob/304749e5c11d0466cfeef3220c91e91401c53167/jni/forwarder.c#L171
9b609c0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe that would work, but it makes seamless VPN handover trickier, as discussed in #62 (comment). Keeping the FD alive on both sides of the boundary allows Java to ensure that the FD isn't closed earlier than it wants.