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
