Hi,
In the case of supplying a filter to getObject the caller is
intentionally replacing
the system filter and can supply a filter that performs it own checks and
if desired can delegate to the system filter.
Some thought does need to be designed into the filter supplied as to
its purpose and edge cases.
Thanks, Roger
On 8/23/18 12:19 PM, Weijun Wang wrote:
But calling getObject(filter) effectively overrides the system filter, is that
a problem?
On Aug 23, 2018, at 11:51 PM, Roger Riggs <roger.ri...@oracle.com> wrote:
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
