[9] request for review: 8048147: Privilege tests with JAAS Subject.doAs

Artem Smotrakov artem.smotrakov at oracle.com
Wed Mar 18 11:31:14 UTC 2015


Yes, it looks like the classes are loaded from test.classes, here is a 
piece of jtr file

CLASSPATH=/home/artem/tools/jtreg/4.1/lib/javatest.jar:/home/artem/tools/jtreg/4.1/lib/jtreg.jar:/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth/Subject/doAs:/home/artem/projects/security_test_colocation/jaas_subject_doas/jdk9_dev/jdk/test/javax/security/auth/Subject/doAs 
\\
     /home/artem/jdk/jdk1.9.0b51/bin/java \\
         -Dtest.vm.opts= \\
         -Dtest.jdk=/home/artem/jdk/jdk1.9.0b51 \\
         -Dtest.timeout.factor=1.0 \\
-Dtest.src.path=/home/artem/projects/security_test_colocation/jaas_subject_doas/jdk9_dev/jdk/test/javax/security/auth/Subject/doAs 
\\
         -Dtest.compiler.opts= \\
         -Dcompile.jdk=/home/artem/jdk/jdk1.9.0b51 \\
-Dtest.classes=/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth/Subject/doAs 
\\
-Dtest.class.path=/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth/Subject/doAs 
\\
         -Dtest.java.opts= \\
-Dtest.src=/home/artem/projects/security_test_colocation/jaas_subject_doas/jdk9_dev/jdk/test/javax/security/auth/Subject/doAs 
\\
         -Dtest.tool.vm.opts= \\
-Djava.security.policy==/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/scratch/policy.expect.ace_new 
\\
         -Djava.security.manager=default \\
         com.sun.javatest.regtest.MainWrapper 
/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth/Subject/doAs/NestedActions.jta 
expectACE

I am not sure that it is possible to modify classpath for othervm tests.

http://openjdk.java.net/jtreg/faq.html#question4.2

...
4.2. How do I set the CLASSPATH environment variable for my test?

The harness sets the CLASSPATH for the compile, main, and applet actions 
to be the system class path plus the test's source and classes directory.

It is possible to set the classpath for the main/othervm action via the 
-classpath option to java. Any other modification of the CLASSPATH must 
be done using the shell action.
...

"@run main/othervm -classpath ..." doesn't seem to work because it can't 
find com.sun.javatest.regtest.MainWrapper

The tests can be updated to start a new process with ProcessTools, or 
use a script.

Artem

On 03/18/2015 12:43 PM, Wang Weijun wrote:
> Honestly, writing a shell script test would be much cleaner, although it does not have the same performance as a Java test.
>
> Copying Jon, there should be cases where a script should be preferred.
>
> --Max
>
>> On Mar 18, 2015, at 17:39, Wang Weijun <weijun.wang at oracle.com> wrote:
>>
>> It looks like the classes are loaded from test.classes since there is nowhere setting classpath to those jars. Maybe you cannot rely on "@run main".
>>
>> --Max
>>
>>> On Mar 18, 2015, at 17:21, Artem Smotrakov <artem.smotrakov at oracle.com> wrote:
>>>
>>> Hi Max,
>>>
>>> Thank you for the review, it really helped to simplify the tests. I combined your suggestions, please take a look:
>>>
>>> http://cr.openjdk.java.net/~asmotrak/8048147/webrev.01/
>>>
>>> Artem
>>>
>>> On 03/17/2015 12:39 PM, Wang Weijun wrote:
>>>> Hi Artem
>>>>
>>>> The tests are good but I am thinking if we can simplify them.
>>>>
>>>> There are too many duplicate actions here, for example, packing the same classes again and again to the same jar file, and the 4 ***Test.java files are quite similar. Is it possible to create a single Test.java to do everything in a single main()?
>>>>
>>>> Is it possible to convert javac calls to @compile or @build? Is it possible to convert jar calls to ZipOutputStream calls in the same VM? Or maybe instead of using jar files is it possible to put the classes into different sub-directories and point classpath to them? Is it possible to convert java calls to @run?
>>>>
>>>> Finally, you create a new nested directory. Is it because there is already a "doAs" there? I'd rather see a doAs2 containing these new tests. The new Utils.java can also be put inside this directory.
>>>>
>>>> BTW, the auth.policy file was so old and I wonder if we still need to test it.
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>>> On Mar 16, 2015, at 18:47, Artem Smotrakov <artem.smotrakov at oracle.com> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Please review a couple of new tests for privilege checks on Subject.doAs().
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8048147
>>>>> http://cr.openjdk.java.net/~asmotrak/8048147/webrev.00/
>>>>>
>>>>> Artem




More information about the security-dev mailing list