> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron
> M. Renn
> Subject: Re: FileDescriptor Support
>
>
> Brian Jones wrote:
> > I was attempting to determine what kind of security/access checks go
> > on with JNI and I couldn't find it
"Aaron M. Renn" <[EMAIL PROTECTED]> writes:
> That's a good idea. I thought that under JNI, access restrictions on
> classes were enforced. But I think that the debugging interface could
> probably get around that if they are.
Access restrictions are not enforced using JNI. Serialization (a
Brian Jones wrote:
> I was attempting to determine what kind of security/access checks go
> on with JNI and I couldn't find it in the JNI information from Sun so
> far. Seems like you could call the static native method anytime from
> my reading if getMethodID succeeded, but I dunno.
That's a go
"Aaron M. Renn" <[EMAIL PROTECTED]> writes:
> -- java.net.SocketImpl and java.net.DatagramSocketImpl have methods that
> return an instance of FileDescriptor
> -- java.lang.Process has methods that return {Input,Output} streams to
> read/write to the subprocess which would most easily be implemen
The issue of FileDescriptor's has come up again. Here are the facts:
-- java.io.FileDescriptor is final
-- java.io.FileDescriptor has no public constructor that can create a valid
object
This is necessary to prevent malicious applications from creating
FileDescriptors for arbitrary native fd's.
5 matches
Mail list logo
