Re: SecurityManager

Surendra Lingareddy <[email protected]> Fri, 19 Dec 2008 08:51:04 -0600
Newsgroups gmane.comp.java.sun.rmi
Message-ID <3FECBF6D7078D543AA66628BB473E161C29D7E@mail1.COMMSTOR.Crossroads.com>
Thanks Tim et.al.

-----Original Message-----
From: Tim Blackman [mailto:[email protected]]=20
Sent: Friday, December 19, 2008 6:44 AM
To: [email protected]
Subject: Re: SecurityManager

On Dec 18, 2008, at 4:55 PM, Gregg Wonderly wrote:

> Surendra Lingareddy wrote:
>> Thanks Greg. Security is quite critical and thus we went the SSL and
>> Certs route. For now, I do have a SecurityManager(SM) in place with =20
>> a policyfile that
>> sets the flag to 'AllPermissions'. That seems equally bad and mucking
>> with it seems to create more problems. My team tried a few controlled
>> edits of the policyfile to provide disk r/w/ex access but clients =20
>> do not
>> seem to make a successful connection to the server when we restrict
>> certain IP and port access.
>> I understand that a SecurityManager is needed when you build a =20
>> generic
>> service. SM checks and provides the stubs to the clients at run-time.
>> But, if you do distribute the stubs as compiled classes, and if the =20
>> only
>> way a client can connect to the server is via SSL, then I fail to see
>> the advantage SM brings into the picture.
>> I would rather not provide one at all than having a policyfile that
>> allows 'allpermissions'.
>
> The predominate issue that I always encounter is the "hidden" =20
> security checks that are not visible.  Things like property value =20
> checks etc. can really be frustrating to work through.  I don't =20
> recall whether it's still visible somewhere or not, but the guys at =20
> Sun, on the Jini team, had a SecurityManager that you could install, =20
> which would accumulate all the permission checks made, and then dump =20
> them out so that you could run an application and get a "default" =20
> policy file pretty easily.  I don't know if that's still around or =20
> not.  Perhaps Peter knows?

Actually, it is a security Policy rather than a SecurityManager.

The class is called com.sun.jini.tool.DebugDynamicPolicyProvider, and =20
is available as part of the Apache River 2.1.1 release -- see:

   http://incubator.apache.org/river/RIVER/downloads.html

- Tim

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D
To unsubscribe, send email to [email protected] and include in the
body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html

CONFIDENTIAL: This email, including its contents and attachments, if =
any, are confidential. If the reader of this e-mail is not an intended =
recipient, you have received this e-mail in error and any review, =
dissemination, distribution or copying is strictly prohibited. If you =
have received this e-mail in error, please notify the sender immediately =
by return e-mail at [[email protected]] and permanently delete =
the copy you received. Copyright and other intellectual property rights =
in its contents are the sole property of Crossroads Systems, Inc. Email =
transmission cannot be guaranteed to be secure or error-free. The sender =
therefore does not accept liability for any errors or omissions in the =
contents of the message which arise as a result of email  transmission.  =
Although we routinely screen for viruses, addressees should check this =
email and any attachments for viruses. We make no representation or =
warranty as to the absence of viruses in this email or any attachments.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html