Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / December 2005

Tip: Looking for answers? Try searching our database.

Security confusion

Thread view: 
stixwix - 21 Dec 2005 14:38 GMT
Hi,

Using Java as it comes 'out the box', the following runs ok:
System.getProperty("user.home");

But if I sub-class SecurityManager thus:
class MySecurityManager extends SecurityManager {}

and then set this up in main:
System.setSecurityManager(new MySecurityManager());

Then the getProperty call throws an access exception.

If i edit the java.policy file to specifically allow this call then it
is ok (this property isn't in the default 'allowed' list).

This implies that the default SecurityManager doesn't use the
java.policy file but I know it does because if you leave a syntax error
in the file you get an exception.

What am I missing here?

Regards,
Andy
Chris Smith - 21 Dec 2005 15:43 GMT
> If i edit the java.policy file to specifically allow this call then it
> is ok (this property isn't in the default 'allowed' list).
>
> This implies that the default SecurityManager doesn't use the
> java.policy file

Huh?  If editing the java.policy file works, then obviously
SecurityManager does use the file.  (Yes, it does, by the way).

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

stixwix - 21 Dec 2005 15:52 GMT
The point is that if I don't declare my own SecurityManager, I don't
need to edit the java.policy file - the call does not throw an
exception (even though this property is not in the policy file's
default list of permissions).

Once I have declared MySecurityManager to be 'the daddy', then the only
way to get the call to work is to explicitly add this call to the
policy file.

cheers
Chris Smith - 21 Dec 2005 16:23 GMT
> The point is that if I don't declare my own SecurityManager, I don't
> need to edit the java.policy file - the call does not throw an
> exception (even though this property is not in the policy file's
> default list of permissions).

I was under the impression that you didn't have a security manager at
all for the first test (as you said, "Java as it comes 'out the box'").  
If you set a security manager for the first test, then that's very odd
indeed, and I don't have an explanation for you.

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Paulus de Boska - 21 Dec 2005 16:17 GMT
In standalone applications there is no default securitymanager . You
can appoint one, as in : System.setSecurityManager.... , that will
enforce the policy files. More on this here :
http://javalessons.com/cgi-bin/fun/java-tutorials-main.cgi?ses=ao789

category 'Advanced', lesson 'Policy files'

---
Paul Hamaker
SEMM
http://javalessons.com
stixwix - 21 Dec 2005 16:32 GMT
Ahhh, the penny drops....
Thanks.

> In standalone applications there is no default securitymanager . You
> can appoint one, as in : System.setSecurityManager.... , that will
[quoted text clipped - 7 lines]
> SEMM
> http://javalessons.com


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.