2 Replies Latest reply on Oct 18, 2019 7:46 PM by smarlow

    WildFly 17 secmgr Permissions




      I'm trying to setup WildFly 17 on Windows 10 to use the security manager without permission restrictions.  The plan is to allow all permissions initially, and then lock the system down later.

      I have successfully enabled the security manager using -secmgr.  I have also set the permissions in the standalone.xml as follows:


      <subsystem xmlns="urn:jboss:domain:security-manager:1.0">



                     <permission class="java.security.AllPermission" />





      However, deployments are still failing with permission messages such as this:

      java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "user.dir" "read")" in code source "(vfs:/C:/path/to/my.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.my.war" from Service Module Loader")


      Further, I have tried setting the minimum permissions as follows, with no change to the error messages:


           <permission class="java.util.PropertyPermission" name="*" actions="read,write" />



      Why am I still seeing permission issues if everything is given java.security.AllPermission?

        • 1. Re: WildFly 17 secmgr Permissions

          I was able to get around most of the issues by including the permissions.xml file with AllPermission into each of my wars.  However, one of my wars is still seeing the issue.  This particular war happens to be from a third party.  My best guess is that there are permissions being set somewhere within the war.  Besides the permissions.xml and the security-manager subsystem in the standalone.xml, are there other places that someone can define permissions?

          • 2. Re: WildFly 17 secmgr Permissions

            Are these standalone WAR deployments or are they contained in an EAR?  As for an EAR, the permissions.xml should be specified at EAR (META-INF/permissions.xml) level.


            Regarding the issue with java.security.AllPermission not doing what you expect, I'm not sure why that it is happening.