Mark initialization of unsafe as privileged#5640
Mark initialization of unsafe as privileged#5640jasontedor wants to merge 1 commit intonetty:4.1from
Conversation
There was a problem hiding this comment.
MpscChunkedArrayQueue goes through its own process of initializing unsafe. Of course, this requires permissions which might not be granted to calling code, so we must mark this block as privileged too.
There was a problem hiding this comment.
@jasontedor can you add this as comment above the block ?
There was a problem hiding this comment.
@jasontedor also maybe open a pr or issue in jctools so it gets fixed there and we can just consume it ? /cc @nitsanw ?
There was a problem hiding this comment.
@normanmaurer I will do those things (add a comment, and open a PR against JCTools).
There was a problem hiding this comment.
I pushed 90a93314433bf3c04a592df42e45e0daa3a81fb9. A PR against JCTools is still forthcoming.
c82fd90 to
a4642cf
Compare
There was a problem hiding this comment.
@jasontedor ah nevermind I did not see its a return and not a throw :(
There was a problem hiding this comment.
I pushed fb11e08beaa3bb4e5c644eba34255d67c361912c.
|
lgtm @jasontedor ... good work! please squash and we can pull this in. |
Motiviation: Preparing platform dependent code for using unsafe requires executing privileged code. The privileged code for initializing unsafe is executed in a manner that would require all code leading up to the initialization to have the requisite permissions. Yet, in a restrictive environment (e.g., under a security policy that only grants the requisite permissions the Netty common jar but not to application code triggering the Netty initialization), then initializing unsafe will not succeed even if the security policy would otherwise permit it. Modifications: This commit marks the necessary blocks as privileged. This enables access to the necessary resources for initialization unsafe. The idea is that we are saying the Netty code is trusted, and as long as the Netty code has been granted the necessary permissions, then we will allow the caller access to these resources even though the caller itself might not have the requisite permissions. Result: Unsafe can be initialized in a restrictive security environment.
65db06e to
11b2aa0
Compare
|
Thanks @Scottmitch, I've squashed as requested. |
|
@jasontedor thanks... pull in now :) |
|
Thanks @normanmaurer. |
Motiviation:
Preparing platform dependent code for using unsafe requires executing
privileged code. The privileged code for initializing unsafe is executed
in a manner that would require all code leading up to the initialization
to have the requisite permissions. Yet, in a restrictive environment
(e.g., under a security policy that only grants the requisite
permissions the Netty common jar but not to application code triggering
the Netty initialization), then initializing unsafe will not succeed
even if the security policy would otherwise permit it.
Modifications:
This commit marks the necessary blocks as privileged. This enables
access to the necessary resources for initialization unsafe. The idea is
that we are saying the Netty code is trusted, and as long as the Netty
code has been granted the necessary permissions, then we will allow the
caller access to these resources even though the caller itself might not
have the requisite permissions.
Result:
Unsafe can be initialized in a restrictive security environment.