[janino-dev] [jira] Created: (JANINO-113) Inner class access to inherited protected violates security

Inner class access to inherited protected violates security
-----------------------------------------------------------

                 Key: JANINO-113
                 URL: http://jira.codehaus.org/browse/JANINO-113
             Project: Janino
          Issue Type: Bug
            Reporter: Matt Fowles
            Assignee: Arno Unkrig
            Priority: Critical


This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112

Consider the following classes:

{code}
public class Parent {
    protected int var = 1;
}

public class Child extends Parent {
    public class Inner {
        public int get() {
            return var;
        }
        public void set() {
            var = 4;
        }
    }
}

public class Main {
    public static void main(String[] args) {
        Child.Inner i = new Child().new Inner();
        System.out.println("before set: " + i.get());
        i.set();
        System.out.println("after set: " + i.get());
    }
}
{code}

If you run this using janinoc as your compiler and java from the command line this will print:

before set: 1
after set: 4

as you would expect.

however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".

Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.

If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:


fowles@spiceweasel:~/sample/java$ javap test/Child
Compiled from "Child.java"
public class test.Child extends other.Parent{
    public test.Child();
    static int access$000(test.Child);
    static int access$102(test.Child, int);
}


Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.


--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

     [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-113:
-------------------------------

    Attachment: indirect.patch

Fix access to inherited protected members within nested class by
- add Java.IndirectFieldAccess to represent this case
- change a few resolution methods to create IndirectFieldAccess object as appropriate
- update all the visitors to work with them
- make the compilers generate synthetic getters and setters for IndirectFieldAccess on demand
- add tests


This patch includes in it the fix to Janino-112.

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134544#action_134544 ]

Matt Fowles commented on JANINO-113:
------------------------------------

I found a verification error when using these synthetic methods in <init> blocks.  More info soon.

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

     [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-113:
-------------------------------

    Attachment: indirect.patch

This patch obsoletes my last one and fixes an extra get of this$0 that was causing verification errors.

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

     [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-113:
-------------------------------

    Attachment:     (was: indirect.patch)

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135010#action_135010 ]

Arno Unkrig commented on JANINO-113:
------------------------------------

Why the heck can "test.Top$Inner.get()" legally access "for_sandbox_tests.ProtectedVariable.var", while
"for_sandbox_tests.Top$Inner.get()" can't? I'd have expected it the other way round, if any.

The JLS says:

"access is permitted [ ... ] when  [ ... ] access to the member or constructor occurs from within the package containing the class in which the protected member or constructor is declared."

So, if "Inner" and "ProtectedVariable" are declared in the same package (which is the case in case one, but not in case two), the access should be legal. Results, however, are precisely vice versa.

Can you please give me some inspiration?

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135017#action_135017 ]

Matt Fowles commented on JANINO-113:
------------------------------------

After further testing, I see that you are correct that this is only a problem when crossing package boundaries.

This was also a bug in the java compiler which took them some time to fix.  You can see their discussion of it here.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4116802

The bug ticket from sun does not include the detail of how they fixed it (using synthetic getter methods), but that can be determined using javap.

Thus this bug can be viewed as a follow on to Janino-112.

The example that I give above, will fail if Child and Parent are in different packages.  Sorry for the confusion.  Regardless, I stand by this patch as a valid fix to the issue.

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135288#action_135288 ]

Arno Unkrig commented on JANINO-113:
------------------------------------

Nope, it's exactly THE OTHER WAY ROUND: The test fails if base and derived class are INTHE SAME PACKAGE. That's what confuses me so much. Tested with IBM JVM 1.5.0-SR5 and SUN JVM 1.4.2_10, 1.5.0_05 and 1.6.0.

How can this be?

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135315#action_135315 ]

Matt Fowles commented on JANINO-113:
------------------------------------

Regardless, the patch that I am offering creates these synthetic field accessors for all cases of accessing an enclosing inherited protected variable and it passes the tests that I have added for it.  It even allows a large chunk of our test at work (which are much more sizeable and onerous) to pass.

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135658#action_135658 ]

Arno Unkrig commented on JANINO-113:
------------------------------------

Yep, your fix could also be the key form the access to PRIVATE members... stay tuned.

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136074#action_136074 ]

Matt Fowles commented on JANINO-113:
------------------------------------

Damn, it looks like we need to do something similar to this for protected methods too.

Arno, do you plan on reimplementing this patch, or is it worth while for me to extend it to protected methods as well?

{code:title=EvaluatorTests.java}
public void testProtectedMethodsAcrossPackage() throws Exception {
        SimpleCompiler sc = new SimpleCompiler();
        sc.setParentClassLoader(SimpleCompiler.BOOT_CLASS_LOADER, new Class[] { for_sandbox_tests.ProtectedVariable.class });
        sc.cook("package for_sandbox_tests;\n" +
                "public class Top extends for_sandbox_tests.ProtectedVariable {\n" +
                "    public class Inner {\n" +
                "        public int get() {\n" +
                "            return getVar();\n" +
                "        }\n" +
                "        public int sget() {\n" +
                "            return sgetVar();\n" +
                "        }\n" +
                "    } \n" +
                "    public Inner createInner() {\n" +
                "        return new Inner();\n" +
                "    }\n" +
                "}"
        );
       
        Class topClass = sc.getClassLoader().loadClass("for_sandbox_tests.Top");
        Method createInner = topClass.getDeclaredMethod("createInner", null);
        Object top = topClass.newInstance();
        Object inner = createInner.invoke(top, null);
       
        Class innerClass = inner.getClass();
        Method[] m = new Method[] {
                innerClass.getDeclaredMethod("get", null),
                innerClass.getDeclaredMethod("sget", null),
        };
       
        for(int i = 0; i < m.length; ++i) {
            Object res = m[i].invoke(inner, null);
            assertEquals(Integer.valueOf(i+1), res);
       }
    }
{code}

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136075#action_136075 ]

Matt Fowles commented on JANINO-113:
------------------------------------

implied in the above comment but not made explicit is that I added protected methods to ProtectedVariable (sgetVar() is static, getVar is non-static)

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136094#action_136094 ]

Arno Unkrig commented on JANINO-113:
------------------------------------

Sigh... who invented these brain dead "access methods" at SUN? If PROTECTED is a run-time security mechanism, then the access methods break security anyway!!!!!

So far, I tried to avoid this problem by implicitly making PRIVATE methods DEFAULT visible (UnitCompiler:1544), and PRIVATE fields also (UnitCompiler:418). This solution is _simple_ (and JANINO favors simplicity over completeness), and works perfectly for enclosing/enclosed types, but not for access to PROTECTED members of the _superclass_ of enclosing/enclosed type, if that superclass is declared in a different package.

A simple workaround (while I temporarily favored) is to make all PROTECTED members silently PUBLIC, so they are accessible from enclosing/enclosed types of derived types declared in a different package, but that works only if the the type declaring the member _is compiled by JANINO_. The workaround is to add setters/getters _in the derived class_ for the PROTECTED field _of the superclass_, and add wrapper methods _in the derived class_ around the PROTECTED method _of the superclass_.

While I'm very happy that someone (=>you!) implements a long-missing, complicated feature, I dislike to have each and every idiocy of the Java language being reimplemented in JANINO. JANINO is not intended to be a reference Java compiler, but a lightweight embedded compiler with its focus on ExpressionEvaluator-like applications.

Let me emphasize that appreciate your work for this issue (and the many others) very much, and that not your concept / design / implementation is an idiocy.

This consideration is very much the same as the considerations pro/con implementing the various Java 5 features. Some I implemented because they were cool, useful, and cheap (autoboxing, static imports), some I didn't because they are not. What if someone offers to implement GENERICS in JANINO?

All in all, I'd say that if someone has a really good use for a feature, and the costs are not too high, then I'd go for it. A good example for this was autoboxing: Someone said "autoboxing is useful for EE", and that is right, so I did it. Someone else said "I want to compile my programs with JANINO, so I need generics", and I replied "please use JAVAC, no plans to implement generics at this time".

Getting back to our issue:
Accessor methods are really sick; JANINO implements a cheap trick that solves 90% of the problem, 5% would be solved by silently making PROTECTED members PUBLIC (as explained above), and there is a workaround for the remaning 5% (setters, getters, wrapper methods). I tend to go that way and the limitation and its worksround. Do you _really need the full functionality_, or could you live with the restriction?

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136118#action_136118 ]

Matt Fowles commented on JANINO-113:
------------------------------------

Unfortunately for our situation that parent class is being compiled by javac, so we need accessors to access the variables.

However, as this is an internal code base, we could probably just make the variables and methods in question public and comment them appropriately.  Thus, it would not be an absolute deal breaker for us.

All in all, I have a mild preference for implementing the full and correct thing, but I can definitely appreciate that this might add more complexity then is desired to Janino.

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138643#action_138643 ]

Arno Unkrig commented on JANINO-113:
------------------------------------

OK... you're three done with the field wrappers, and the method wrapper are probably very much the same. So... be it an idiocy or not... go for it if you're willing!

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138643#action_138643 ]

aunkrig edited comment on JANINO-113 at 6/18/08 2:45 PM:
-------------------------------------------------------------

OK... you're three quarters done with the field wrappers, and the method wrapper are probably very much the same. So... be it an idiocy or not... go for it if you're willing!

      was (Author: aunkrig):
    OK... you're three done with the field wrappers, and the method wrapper are probably very much the same. So... be it an idiocy or not... go for it if you're willing!
 

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
>                 Key: JANINO-113
>                 URL: http://jira.codehaus.org/browse/JANINO-113
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>            Priority: Critical
>         Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
>     protected int var = 1;
> }
> public class Child extends Parent {
>     public class Inner {
>         public int get() {
>             return var;
>         }
>         public void set() {
>             var = 4;
>         }
>     }
> }
> public class Main {
>     public static void main(String[] args) {
>         Child.Inner i = new Child().new Inner();
>         System.out.println("before set: " + i.get());
>         i.set();
>         System.out.println("after set: " + i.get());
>     }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy.  The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders.  As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
>     public test.Child();
>     static int access$000(test.Child);
>     static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base.  Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email