[12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject

[Weijun Wang]

But calling getObject(filter) effectively overrides the system filter, is that a problem?

> On Aug 23, 2018, at 11:51 PM, Roger Riggs <roger.riggs at 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.riggs at 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.mullan at 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
>