About Question enthuware.ocpjp.v11.2.3618 :
Moderator: admin
-
- Posts: 7
- Joined: Wed Aug 12, 2020 4:44 am
- Contact:
About Question enthuware.ocpjp.v11.2.3618 :
Hi there,
I guess there has to be something wrong. The explanation to answer four suggests the same code as stated in the question. Especially the line with "//<----- Observe this argument" is the same.
Kind regards
I guess there has to be something wrong. The explanation to answer four suggests the same code as stated in the question. Especially the line with "//<----- Observe this argument" is the same.
Kind regards
-
- Site Admin
- Posts: 10036
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v11.2.3618 :
In the problem statement, the second argument is noPermissionsAcc, while in the example, it is AccessController.getContext()
If you like our products and services, please help us by posting your review here.
-
- Posts: 7
- Joined: Wed Aug 12, 2020 4:44 am
- Contact:
Re: About Question enthuware.ocpjp.v11.2.3618 :
Maybe I just don't get it?
This refers to "SecureClass1" from the problem statement, right?...If the developer wants to SecureClass1.getProp method to check permissions of its caller, then the two argument doPrivilege method should be invoked, where the second argument is the permissions of its caller. Like this:
Code: Select all
public static String getProp(final String propName) { return AccessController.doPrivileged( new PrivilegedAction<String>() { public String run() { return System.getProperty(propName); } } , AccessController.getContext() //<----- Observe this argument ); }
Code: Select all
public class SecureClass1 { public static String getProp(final String propName) { return AccessController.doPrivileged( new PrivilegedAction<String>() { public String run() { return System.getProperty(propName); } }, AccessController.getContext() ); } }
-
- Posts: 7
- Joined: Wed Aug 12, 2020 4:44 am
- Contact:
Re: About Question enthuware.ocpjp.v11.2.3618 :
It could be that it is about the caller of "SecureClass1" and the code stated in the explanation is just an example. So the code could look like this:
Code: Select all
public static void doWork(final String propName){
AccessController.doPrivileged( new PrivilegedAction<Void>() {
public Void run() {
System.out.println("In SecureClass2 : "+SecureClass1.getProp(propName));
return null;
}
//}, noPermissionsAcc); <----- Delete this argument
}, AccessController.getContext()); // <----- Insert this argument
}
-
- Posts: 7
- Joined: Wed May 03, 2017 8:14 am
- Contact:
Re: About Question enthuware.ocpjp.v11.2.3618 :
sorry, but the question is wrong and the explentaion in NOT correct
Please admin, correct the questione because is very important for the exam!
The code in the question show a method getProp() in the class SecureClass1 WITH AnccessController.getContext(). THEN the execution go to in SecurityException! Because take the execution context from the method doWork() in the class SecureClass1. And SecureClass2 have an execution context with no privileges!
For me, the file policy for a.jar, in this scenario, is not enough! The code go to SecurityException in any case!
Please write more explenation.
Many Thanks
Please admin, correct the questione because is very important for the exam!
The code in the question show a method getProp() in the class SecureClass1 WITH AnccessController.getContext(). THEN the execution go to in SecurityException! Because take the execution context from the method doWork() in the class SecureClass1. And SecureClass2 have an execution context with no privileges!
For me, the file policy for a.jar, in this scenario, is not enough! The code go to SecurityException in any case!
Please write more explenation.
Many Thanks
-
- Site Admin
- Posts: 10036
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v11.2.3618 :
This thread somehow slid through the cracks and was left unanswered. Sorry about that.
futurecap was right. The code for SecureClass1.java in the problem statement actually uses the second parameter and so, it correctly uses the callers privileges. It will, therefore, not be able to read java.home property because the caller has passed in a context with no permissions.
The code for SecureClass1.java has now been updated to :
Now, with the above change, option 4 is correct and the explanation is also correct. The code given in the explanation is for SecureClass1.java and this has now been updated to made clear.
futurecap was right. The code for SecureClass1.java in the problem statement actually uses the second parameter and so, it correctly uses the callers privileges. It will, therefore, not be able to read java.home property because the caller has passed in a context with no permissions.
The code for SecureClass1.java has now been updated to :
Code: Select all
public class SecureClass1 {
public static String getProp(final String propName) {
return AccessController.doPrivileged(
new PrivilegedAction<String>() {
public String run() {
return System.getProperty(propName);
}
} //NO SECOND PARAMETER HERE
);
}
}
The code will work without any issue because SecureClass1.getProp method gets its own permissions from the policy file. It does not check the permissions associated with its caller (i.e. SecureClass2.doWork).
If the developer wants to SecureClass1.getProp method to check permissions of its caller, then the two argument doPrivilege method should be invoked, where the second argument is the permissions of its caller. Like this:
In this case, the noPermissionsAcc sent by the calling method will take effect and the permission to read java.home property will be denied even though a.jar has the permission to read the property because the action is performed with the intersection of the permissions possessed by the caller's protection domain, and those possessed by the domains represented by the specified AccessControlContext.Code: Select all
public class SecureClass1 { public static String getProp(final String propName) { return AccessController.doPrivileged( new PrivilegedAction<String>() { public String run() { return System.getProperty(propName); } } , AccessController.getContext() //<----- Observe this argument ); } }
If you like our products and services, please help us by posting your review here.
-
- Posts: 7
- Joined: Wed May 03, 2017 8:14 am
- Contact:
Re: About Question enthuware.ocpjp.v11.2.3618 :
perfect
Many thanks
Many thanks
Who is online
Users browsing this forum: No registered users and 57 guests