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 >
