Details

    • Target Release:
    • Steps to Reproduce:
      Hide

      1. store the attached reproducer permissions.war to /tmp
      2. start WildFly/EAP with the security manager enabled (./standalone.sh -secmgr)
      3. configure the permissions maximum-set (only one FilePermission added):

      ./jboss-cli.sh -c << EOT
      /subsystem=security-manager/deployment-permissions=default:write-attribute(name=maximum-permissions, value=[{class=java.io.FilePermission, actions=read, name=\"/-\"}])
      reload
      EOT
      

      4. deploy the reproducer: ./jboss-cli.sh -c "deploy /tmp/permissions.war"

      The deployment should fail.

      You can go to http://localhost:8080/permissions/ and check the output.

      Show
      1. store the attached reproducer permissions.war to /tmp 2. start WildFly/EAP with the security manager enabled ( ./standalone.sh -secmgr ) 3. configure the permissions maximum-set (only one FilePermission added): ./jboss-cli.sh -c << EOT /subsystem=security-manager/deployment-permissions= default :write-attribute(name=maximum-permissions, value=[{class=java.io.FilePermission, actions=read, name=\ "/-\" }]) reload EOT 4. deploy the reproducer: ./jboss-cli.sh -c "deploy /tmp/permissions.war" The deployment should fail. You can go to http://localhost:8080/permissions/ and check the output.
    • Affects:
      Release Notes
    • Release Notes Docs Status:
      Documented as Resolved Issue
    • Release Notes Text:
      Hide
      Known Issues

      What actions or circumstances cause the problem?
      The configuration of an empty security manager maximum set leads to AllPermission being used. When admins deliberately configure an empty set they are really trying to establish an empty permission collection to block any deployments that have declared permissions. The default AllPermission that is assigned in this case forbids this scenario and leads to the opposite behavior (i.e. any declared permission is accepted by the subsystem).

      How does the problem effect the example/archetype/framework?
      It prevents admins from blocking deployments that have declared security permissions. There might be a policy in place to block these deployments and the current behavior doesn't allow for that.

      Does a workaround exist and what is it?
      Admins always have the option of checking if deployments have permissions (in META-INF/permissions.xml) and simply not deploy them instead of relying on the subsystem to perform this check for them.

      What now happens to the example/archetype/framework when the workaround is used?
      Deployments that are to be rejected because they require security permissions are not deployed.
      Show
      Known Issues What actions or circumstances cause the problem? The configuration of an empty security manager maximum set leads to AllPermission being used. When admins deliberately configure an empty set they are really trying to establish an empty permission collection to block any deployments that have declared permissions. The default AllPermission that is assigned in this case forbids this scenario and leads to the opposite behavior (i.e. any declared permission is accepted by the subsystem). How does the problem effect the example/archetype/framework? It prevents admins from blocking deployments that have declared security permissions. There might be a policy in place to block these deployments and the current behavior doesn't allow for that. Does a workaround exist and what is it? Admins always have the option of checking if deployments have permissions (in META-INF/permissions.xml) and simply not deploy them instead of relying on the subsystem to perform this check for them. What now happens to the example/archetype/framework when the workaround is used? Deployments that are to be rejected because they require security permissions are not deployed.

      Description

      Configuration of maximum-permissions attribute in /subsystem=security-manager/deployment-permissions=default doesn't work so the permissions for deployments can't be restricted.
      (The "policy of the product installation" in the words of EE specification is not enforced).

      If administrator specifies maximum-permissions in server configuration and also permissions.xml in the deployment, all permissions from the permissions.xml are granted even if the policies are in conflict.

      The maximum-permissions configuration has following meaning:
      A set containing the maximum permission scope that can be granted to deployments or jars

      The Java EE 7 platform specification (JSR 342) says in section EE.6.2.2.1:
      If security permissions are declared that conflict with the policy of the product installation, the Java EE product must fail deployment of the application module.

      Expected behavior:

      • based on EE spec the deployment should fail
      • deployed application should not get more permissions than specified in the maximum-permissions

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  sguilhen Stefan Guilhen
                  Reporter:
                  jcacek Josef Cacek
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  14 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: