Page 1 of 1

About Question enthuware.ocpjp.v11.2.3618 :

Posted: Wed Dec 09, 2020 5:16 pm
by futurecap
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

Re: About Question enthuware.ocpjp.v11.2.3618 :

Posted: Wed Dec 09, 2020 9:17 pm
by admin
In the problem statement, the second argument is noPermissionsAcc, while in the example, it is AccessController.getContext()

Re: About Question enthuware.ocpjp.v11.2.3618 :

Posted: Thu Dec 10, 2020 4:10 am
by futurecap
Maybe I just don't get it?
...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
                );
            }
This refers to "SecureClass1" from the problem statement, right?

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()
                );
            }
}

Re: About Question enthuware.ocpjp.v11.2.3618 :

Posted: Thu Dec 10, 2020 4:21 am
by futurecap
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
     }

Re: About Question enthuware.ocpjp.v11.2.3618 :

Posted: Thu Jan 28, 2021 1:30 pm
by doriamauro@gmail.com
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

Re: About Question enthuware.ocpjp.v11.2.3618 :

Posted: Fri Jan 29, 2021 12:00 am
by admin
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 :

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
                );
            }
}
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.
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:

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
                );
            }
}
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.

Re: About Question enthuware.ocpjp.v11.2.3618 :

Posted: Fri Jan 29, 2021 9:47 am
by doriamauro@gmail.com
perfect
Many thanks