About Question enthuware.ocpjp.v11.2.3618 :

Help and support on OCA OCP Java Programmer Certification Questions
1Z0-808, 1Z0-809, 1Z0-815, 1Z0-816, 1Z0-817

Moderator: admin

Post Reply
futurecap
Posts: 7
Joined: Wed Aug 12, 2020 4:44 am
Contact:

About Question enthuware.ocpjp.v11.2.3618 :

Post 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

Online
admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

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

Post by admin »

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.

futurecap
Posts: 7
Joined: Wed Aug 12, 2020 4:44 am
Contact:

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

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

futurecap
Posts: 7
Joined: Wed Aug 12, 2020 4:44 am
Contact:

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

Post 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
     }

doriamauro@gmail.com
Posts: 7
Joined: Wed May 03, 2017 8:14 am
Contact:

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

Post 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

Online
admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

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

Post 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.
If you like our products and services, please help us by posting your review here.


Post Reply

Who is online

Users browsing this forum: admin, Google [Bot] and 59 guests