Hi Max,
Yes, the stream is passed to the readObject method of the classes being
deserialized.
But that's only a concern during the call to a.readObject() not on the
call to setObjectInputFilter.
It would be reasonable I think for getObject0 to put a doPriv around the
call to a.setObjectInputFilter(filter).
Then it would not be necessary to document the security exception nor
need for a permission
and making it easier to understand. The Signed/Sealed object should be
free to set the filter regardless
of the current SM.
Roger
On 8/23/18 11:14 AM, Weijun Wang wrote:
You mean during deserialization an untrusted object could be created that have
a reference to the stream itself?
On Aug 23, 2018, at 10:12 PM, Roger Riggs <roger.ri...@oracle.com> wrote:
Hi,
The original basis for the security manager check was to ensure that the filter
could
not be replaced by untrusted code including code in the classes being
deserialized
that have access to the ObjectInputStream.
Regards, Roger
On 8/23/18 10:00 AM, Weijun Wang wrote:
This follows the convention of ObjectInputStream::setObjectInputFilter. IMHO,
in that case the caller also creates the filter and it's only set on this input
stream.
Maybe we shouldn't have added the permission check there?
Thanks
Max
On Aug 23, 2018, at 4:55 AM, Sean Mullan <sean.mul...@oracle.com> wrote:
One thing I am curious about. Is there a reason why
getObject(ObjectInputFilter) requires a permission check?
In this case, the caller is the one creating the filter and passing it in, so
the caller can only cause harm to themselves, and the ObjectInputStream is a
local variable which is not returned. This method also does not mutate the
contents of the SignedObject (or SealedObject) ... so I don't see the risk
here. I think you can just wrap ObjectInputStream.setObjectInputFilter in
doPrivileged.
--Sean
