Hi Brian and all, err, my own observation differs from yours. I've rebuild Wildfly from the last content of the master branch and get the same privileges on the jboss-modules.jar (so -rw-rw-r-- and not as you are seeing rwxr--r--). Same with the domain folder, which turns out on my local system associated to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a transcript of what I did - maybe you can spot why our results differs so much. $ git show commit 46e119c65d9e32bc0ec69f3933267fece959ed3f Merge: 051f080 c7d9075 Author: Kabir Khan <kkhan(a)redhat.com&gt; Date: Tue Nov 28 17:46:40 2017 +0000 Merge pull request #10669 from praxeo/WFLY-9284 WFLY-9284 Correct MVN env variable to mvnw.cmd $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d wildfly-12.zip ... $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov. 11:41 wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/ -d drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov. 11:41 wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/ Checking all the jars in the distribution, they all appears to have the mask '-rw-rw-r--': $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done | sed -e '/-rw-rw-r--/d' $ Regarding properties files, here is the exhaustive list of properties that RPM packaging has modified the privileges of: appclient/configuration/logging.properties rw------- domain/configuration/application-roles.properties rw------- domain/configuration/default-server-logging.properties rw------- domain/configuration/logging.properties rw------- domain/configuration/mgmt-groups.properties rw------- standalone/configuration/application-roles.properties rw------- standalone/configuration/logging.properties rw------- standalone/configuration/mgmt-groups.properties rw------- If I compare that with the content of the extract zip (same fresh built as above), I can see that 4 files are not having the same mask (rw------): $ for file in $(cut -f1 -d\ ../../../list-props-files.txt ); do ls -l $file ; done -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov. 11:41 appclient/configuration/logging.properties -rw-------. 1 rpelisse rpelisse 710 30 nov. 11:41 domain/configuration/ application-roles.properties -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov. 11:41 domain/configuration/default-server-logging.properties -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov. 11:41 domain/configuration/logging.properties -rw-------. 1 rpelisse rpelisse 669 30 nov. 11:41 domain/configuration/mgmt-groups.properties -rw-------. 1 rpelisse rpelisse 711 30 nov. 11:41 standalone/configuration/application-roles.properties -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov. 11:41 standalone/configuration/logging.properties -rw-------. 1 rpelisse rpelisse 669 30 nov. 11:41 standalone/configuration/mgmt-groups.properties Now, as you said, those files privileges are indeed fine-grained, so maybe we can push back to people making the RPM for them to NOT change the following files privileges: -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov. 11:41 appclient/configuration/logging.properties -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov. 11:41 domain/configuration/default-server-logging.properties -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov. 11:41 domain/configuration/logging.properties -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov. 11:41 standalone/configuration/logging.properties However, I don't see the value of letting those files accessible either group member or any user on the system, but maybe we can make the argument they should. But the write privileges for group member sounds wrong to me. Also, I'm puzzled Brian and I are seeing different things - am I looking at the correct zipfile here ? Note: You also mention the module.xml - as far as I can see from the diff provided with issue JBEAP-12374, I don't see any issue with privileges regarding those files, so we can remove them of the discussion. The only changes we need to discuss is removing the 'write' privileges' for the group on jars, reducing the scope of permissions on (some) folders, and privileges on (some) properties files. So, module.xml are out of the scope. On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > Seems I forgot to "Reply to All" yesterday. The following was meant to be > sent to wildfly-dev. > > On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> Before getting into the specifics, first a general note re: perms. >> >> Our general permission set for is rwxr-xr-x for directories and >> rwxr--r-- for files. If someone thinks that's wrong in general; speak up. >> ;). Otherwise I think any deviation from that we should justify. Not that >> deviations are wrong, just that they need to have a reason. >> >> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran(a)redhat.com&gt; >> wrote: >> >>> Well, the diff is between the RPM and the zipfile is pretty long, but >>> it boils down to the 3 set of differences I've pointed out on >>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574> >>> >>> - *.properties and .jar* files are associated with the mask >>> rw-rw-r-- giving access to it to any other users and allowing group member >>> to modify the file - the RPM distribution fixes that by removing the write >>> privileges for the group (rw-r--r--). I personnaly don't see the value of >>> letting the group members modify those files, I just can see how this could >>> be exploited, so I would say it falls into "clearly wrong and not our >>> intent". A case might be made for the .properties files, but for jars file >>> I really don't see a valid use case (unless of course, any of you know one) >>> ; >>> >>> There are a few different things here, so let's deal with them >> separately. >> >> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as >> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I >> don't see why they should vary from the general standard. And the >> module.xml file should be consistent, since there's not much point in >> locking people from touching jars but letting them change what jars get >> loaded. >> >> For properties files, let's consider them on a more fine-grained basis. >> For example, the properties files used by the security realms have >> different kinds of data than logging.properties does. >> >> The perms on the security realm property files are rw-------, not >> rw-rw-r--. >> >> The logging.properties files are rw-r--r-- which is consistent with the >> domain|host|standalone.xml files and with the general standard. >> >> >>> >>> - >>> - *some directories* like 'domain/tmp/auth' have too restrictive >>> mask like rwx------ and RPMS to turned them into rwxrwxr-x (that I don't >>> really agree with) and >>> >>> >>> - *other directories*, likes 'domain' have again a too permissive >>> mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make senses. >>> >>> In the unzip I see these directories as rwxr-xr-x, which I think is >> fine. >> >> Are you concerned with any other directories besides $JBOSS_HOME/domain >> and $JBOSS_HOME/standalone? >> >>> So we need to find an agreement on those three items, and then see how >>> we proceed to implement the fix (if needed). >>> >>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> I think we need to start with the assumption that the permissions we >>>> have in the zip are the way they are for a reason and evaluate possible >>>> changes based on discussion here of each type of change. Maybe the RPM >>>> settings are better, maybe they are not. Or maybe they are better but the >>>> improvement is not worth the disruption a change may cause to our end >>>> users, who may rely on the current zip settings. Or maybe what we have in >>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll >>>> probably see a little of each category, although hopefully some changes for >>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :) >>>> >>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <belaran(a)redhat.com&gt; >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> As reported on JBEAP-12374[1], there is some discrepancies between >>>>> the ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those >>>>> discrepancies - or the most relevant ones, are some fine tuning performed >>>>> on the (POSIX) privileges (things such as removing the write privilege for >>>>> member of the same group as the owner of the file). >>>>> >>>>> I've looked into this and because those files are produced by our own >>>>> Maven plugin (as part of wildfly-build-tools), we can not simply modify the >>>>> assembly.xml. Which actually is probably for the best, as it would made the >>>>> assembly file quite cumbersome. >>>>> >>>>> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, but >>>>> when I reported the problem on WFLY-9574[3], Brian suggested I started a >>>>> discussion here. So does anyone have a (strong) opinion about this issue >>>>> and/or how to resolve it ? :) >>>>> >>>>> (For the record, I do think it is best to fix the privileges to >>>>> follow what the RPM does for us for now, but if you feel this issue should >>>>> not be addressed, and dev- the issue, I'm certainly not opposed to it >>>>> either). >>>>> >>>>> [1] https://issues.jboss.org/browse/JBEAP-12374 >>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40 >>>>> [3] https://issues.jboss.org/browse/WFLY-9574 >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Manager, Senior Principal Software Engineer >>>> Red Hat >>>> >>> >>> >> >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> Red Hat >> > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat >

A slightly different topic, related to the "logging.properties/xml config file" topic is whether these files should be world and/or group readable. Changing this has been proposed in the past on the EAP side, primarily based on the argument that users could put sensitive data in these files. This thread seems like a good time to debate this a bit in community. I've resisted that primarily on the basis of: 1) These files or those similarly used have had these perms as far back as I can find in JBoss AS. So the odds that some people are relying upon those perms is fairly high and we need to assume a change would be a breaking change for some people. 2) Other software I've looked at like Tomcat and httpd have similar permission schemes to what we have for their config files, which can also potentially include sensitive data. 3) We provide facilities like the vault or elytron credential store refs for keeping sensitive data out of the config files. On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > Thanks, Romain. > > Re: what the actual permissions are, FWIW I get what I see on both my > macbook and my Fedora 27 machine, both when unzipping the actual > 11.0.0.Final and when unzipping the result of a build of master, and both > with and without the -Prelease -Pjboss-release args to maven that we > include when doing actual releases. Unzipping the zip in build/target > doesn't include the jars of course. > > So it sounds like we need input from others. > > Re: modules.xml, if you are seeing those as rw-r--r-- as well, then +1 to > ignoring them in further discussion. > > Re: logging.properties, those serve a very similar conceptual role to the > standalone|host|domain.xml files so I see no reason for them to have > different perms. However, you and I are getting different results, where > you report them as group writable and I don't. What do you see for the xml > config files? > > Re: RPM changing to match WildFly, that's an EAP discussion, so that can > be taken up elsewhere once we have WildFly the way we want it. > > > On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran(a)redhat.com&gt; > wrote: > >> Hi Brian and all, >> >> err, my own observation differs from yours. I've rebuild Wildfly from >> the last content of the master branch and get the same privileges on the >> jboss-modules.jar (so -rw-rw-r-- and not as you are seeing rwxr--r--). >> Same with the domain folder, which turns out on my local system associated >> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a >> transcript of what I did - maybe you can spot why our results differs so >> much. >> >> $ git show >> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f >> Merge: 051f080 c7d9075 >> Author: Kabir Khan <kkhan(a)redhat.com&gt; >> Date: Tue Nov 28 17:46:40 2017 +0000 >> >> Merge pull request #10669 from praxeo/WFLY-9284 >> >> WFLY-9284 Correct MVN env variable to mvnw.cmd >> >> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d >> wildfly-12.zip >> ... >> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar >> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov. 11:41 >> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar >> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/ -d >> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov. 11:41 >> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/ >> >> Checking all the jars in the distribution, they all appears to have the >> mask '-rw-rw-r--': >> >> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done | sed >> -e '/-rw-rw-r--/d' >> $ >> >> Regarding properties files, here is the exhaustive list of properties >> that RPM packaging has modified the privileges of: >> >> appclient/configuration/logging.properties rw------- >> domain/configuration/application-roles.properties rw------- >> domain/configuration/default-server-logging.properties rw------- >> domain/configuration/logging.properties rw------- >> domain/configuration/mgmt-groups.properties rw------- >> standalone/configuration/application-roles.properties rw------- >> standalone/configuration/logging.properties rw------- >> standalone/configuration/mgmt-groups.properties rw------- >> >> If I compare that with the content of the extract zip (same fresh built >> as above), I can see that 4 files are not having the same mask (rw------): >> >> $ for file in $(cut -f1 -d\ ../../../list-props-files.txt ); do ls -l >> $file ; done >> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov. 11:41 >> appclient/configuration/logging.properties >> -rw-------. 1 rpelisse rpelisse 710 30 nov. 11:41 >> domain/configuration/application-roles.properties >> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov. 11:41 >> domain/configuration/default-server-logging.properties >> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov. 11:41 >> domain/configuration/logging.properties >> -rw-------. 1 rpelisse rpelisse 669 30 nov. 11:41 >> domain/configuration/mgmt-groups.properties >> -rw-------. 1 rpelisse rpelisse 711 30 nov. 11:41 >> standalone/configuration/application-roles.properties >> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov. 11:41 >> standalone/configuration/logging.properties >> -rw-------. 1 rpelisse rpelisse 669 30 nov. 11:41 >> standalone/configuration/mgmt-groups.properties >> >> Now, as you said, those files privileges are indeed fine-grained, so >> maybe we can push back to people making the RPM for them to NOT change the >> following files privileges: >> >> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov. 11:41 >> appclient/configuration/logging.properties >> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov. 11:41 >> domain/configuration/default-server-logging.properties >> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov. 11:41 >> domain/configuration/logging.properties >> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov. 11:41 >> standalone/configuration/logging.properties >> >> However, I don't see the value of letting those files accessible either >> group member or any user on the system, but maybe we can make the argument >> they should. But the write privileges for group member sounds wrong to me. >> >> Also, I'm puzzled Brian and I are seeing different things - am I looking >> at the correct zipfile here ? >> >> Note: You also mention the module.xml - as far as I can see from the >> diff provided with issue JBEAP-12374, I don't see any issue with privileges >> regarding those files, so we can remove them of the discussion. The only >> changes we need to discuss is removing the 'write' privileges' for the >> group on jars, reducing the scope of permissions on (some) folders, and >> privileges on (some) properties files. So, module.xml are out of the scope. >> >> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> Seems I forgot to "Reply to All" yesterday. The following was meant to >>> be sent to wildfly-dev. >>> >>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> Before getting into the specifics, first a general note re: perms. >>>> >>>> Our general permission set for is rwxr-xr-x for directories and >>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up. >>>> ;). Otherwise I think any deviation from that we should justify. Not that >>>> deviations are wrong, just that they need to have a reason. >>>> >>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran(a)redhat.com&gt; >>>> wrote: >>>> >>>>> Well, the diff is between the RPM and the zipfile is pretty long, but >>>>> it boils down to the 3 set of differences I've pointed out on >>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574> >>>>> >>>>> - *.properties and .jar* files are associated with the mask >>>>> rw-rw-r-- giving access to it to any other users and allowing group member >>>>> to modify the file - the RPM distribution fixes that by removing the write >>>>> privileges for the group (rw-r--r--). I personnaly don't see the value of >>>>> letting the group members modify those files, I just can see how this could >>>>> be exploited, so I would say it falls into "clearly wrong and not our >>>>> intent". A case might be made for the .properties files, but for jars file >>>>> I really don't see a valid use case (unless of course, any of you know one) >>>>> ; >>>>> >>>>> There are a few different things here, so let's deal with them >>>> separately. >>>> >>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as >>>> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I >>>> don't see why they should vary from the general standard. And the >>>> module.xml file should be consistent, since there's not much point in >>>> locking people from touching jars but letting them change what jars get >>>> loaded. >>>> >>>> For properties files, let's consider them on a more fine-grained >>>> basis. For example, the properties files used by the security realms have >>>> different kinds of data than logging.properties does. >>>> >>>> The perms on the security realm property files are rw-------, not >>>> rw-rw-r--. >>>> >>>> The logging.properties files are rw-r--r-- which is consistent with >>>> the domain|host|standalone.xml files and with the general standard. >>>> >>>> >>>>> >>>>> - >>>>> - *some directories* like 'domain/tmp/auth' have too restrictive >>>>> mask like rwx------ and RPMS to turned them into rwxrwxr-x (that I don't >>>>> really agree with) and >>>>> >>>>> >>>>> - *other directories*, likes 'domain' have again a too permissive >>>>> mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make senses. >>>>> >>>>> In the unzip I see these directories as rwxr-xr-x, which I think is >>>> fine. >>>> >>>> Are you concerned with any other directories besides >>>> $JBOSS_HOME/domain and $JBOSS_HOME/standalone? >>>> >>>>> So we need to find an agreement on those three items, and then see >>>>> how we proceed to implement the fix (if needed). >>>>> >>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry < >>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>> >>>>>> I think we need to start with the assumption that the permissions we >>>>>> have in the zip are the way they are for a reason and evaluate possible >>>>>> changes based on discussion here of each type of change. Maybe the RPM >>>>>> settings are better, maybe they are not. Or maybe they are better but the >>>>>> improvement is not worth the disruption a change may cause to our end >>>>>> users, who may rely on the current zip settings. Or maybe what we have in >>>>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll >>>>>> probably see a little of each category, although hopefully some changes for >>>>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :) >>>>>> >>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <belaran(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> As reported on JBEAP-12374[1], there is some discrepancies between >>>>>>> the ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those >>>>>>> discrepancies - or the most relevant ones, are some fine tuning performed >>>>>>> on the (POSIX) privileges (things such as removing the write privilege for >>>>>>> member of the same group as the owner of the file). >>>>>>> >>>>>>> I've looked into this and because those files are produced by our >>>>>>> own Maven plugin (as part of wildfly-build-tools), we can not simply modify >>>>>>> the assembly.xml. Which actually is probably for the best, as it would made >>>>>>> the assembly file quite cumbersome. >>>>>>> >>>>>>> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, >>>>>>> but when I reported the problem on WFLY-9574[3], Brian suggested I started >>>>>>> a discussion here. So does anyone have a (strong) opinion about this issue >>>>>>> and/or how to resolve it ? :) >>>>>>> >>>>>>> (For the record, I do think it is best to fix the privileges to >>>>>>> follow what the RPM does for us for now, but if you feel this issue should >>>>>>> not be addressed, and dev- the issue, I'm certainly not opposed to it >>>>>>> either). >>>>>>> >>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374 >>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40 >>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Brian Stansberry >>>>>> Manager, Senior Principal Software Engineer >>>>>> Red Hat >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Manager, Senior Principal Software Engineer >>>> Red Hat >>>> >>> >>> >>> >>> -- >>> Brian Stansberry >>> Manager, Senior Principal Software Engineer >>> Red Hat >>> >> >> > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat

On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse <belaran(a)redhat.com&gt; wrote: > Hi Brian (and all), > > I honestly understand your resistance, and I'm completely fine if we end > up closing this all issue as WONTDO or REJECTED. I just do want to have a > discussion about it and come back with clear reasons and motivations for > changing or not the privileges of each of those files. > Thanks for doing this! There have been a number of issues filed over the last year or so on this general topic so I'm very happy to see them getting addressed here via the WildFly community. Most of the issues I've been talking about are JBEAP issues in JIRA, which is fine, but the best way to get this solid is to get WildFly the way we want it first. Even on the config file read perms thing I mentioned in my last post, I'm personally resistant to changing it, but my biggest resistance is to doing that without a full community discussion. > Given that we see different things on our local setup, I think the best > will be to use a build on a CI Server and works from what we see there. Is > there an easy way for me to clone a job building Wildfly and tweak it on > some (publicly) accessible instance ? > https://developer.jboss.org/thread/224262 describes how to get a zip built from a daily CI job. If anyone has any insights on this, please speak up! > > > On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> A slightly different topic, related to the "logging.properties/xml >> config file" topic is whether these files should be world and/or group >> readable. >> >> Changing this has been proposed in the past on the EAP side, primarily >> based on the argument that users could put sensitive data in these files. >> This thread seems like a good time to debate this a bit in community. >> >> I've resisted that primarily on the basis of: >> >> 1) These files or those similarly used have had these perms as far back >> as I can find in JBoss AS. So the odds that some people are relying upon >> those perms is fairly high and we need to assume a change would be a >> breaking change for some people. >> >> 2) Other software I've looked at like Tomcat and httpd have similar >> permission schemes to what we have for their config files, which can also >> potentially include sensitive data. >> >> 3) We provide facilities like the vault or elytron credential store refs >> for keeping sensitive data out of the config files. >> >> >> On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> Thanks, Romain. >>> >>> Re: what the actual permissions are, FWIW I get what I see on both my >>> macbook and my Fedora 27 machine, both when unzipping the actual >>> 11.0.0.Final and when unzipping the result of a build of master, and both >>> with and without the -Prelease -Pjboss-release args to maven that we >>> include when doing actual releases. Unzipping the zip in build/target >>> doesn't include the jars of course. >>> >>> So it sounds like we need input from others. >>> >>> Re: modules.xml, if you are seeing those as rw-r--r-- as well, then +1 >>> to ignoring them in further discussion. >>> >>> Re: logging.properties, those serve a very similar conceptual role to >>> the standalone|host|domain.xml files so I see no reason for them to have >>> different perms. However, you and I are getting different results, where >>> you report them as group writable and I don't. What do you see for the xml >>> config files? >>> >>> Re: RPM changing to match WildFly, that's an EAP discussion, so that >>> can be taken up elsewhere once we have WildFly the way we want it. >>> >>> >>> On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran(a)redhat.com&gt; >>> wrote: >>> >>>> Hi Brian and all, >>>> >>>> err, my own observation differs from yours. I've rebuild Wildfly from >>>> the last content of the master branch and get the same privileges on the >>>> jboss-modules.jar (so -rw-rw-r-- and not as you are seeing rwxr--r--). >>>> Same with the domain folder, which turns out on my local system associated >>>> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a >>>> transcript of what I did - maybe you can spot why our results differs so >>>> much. >>>> >>>> $ git show >>>> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f >>>> Merge: 051f080 c7d9075 >>>> Author: Kabir Khan <kkhan(a)redhat.com&gt; >>>> Date: Tue Nov 28 17:46:40 2017 +0000 >>>> >>>> Merge pull request #10669 from praxeo/WFLY-9284 >>>> >>>> WFLY-9284 Correct MVN env variable to mvnw.cmd >>>> >>>> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d >>>> wildfly-12.zip >>>> ... >>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules. >>>> jar >>>> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov. 11:41 >>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar >>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/ -d >>>> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov. 11:41 >>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/ >>>> >>>> Checking all the jars in the distribution, they all appears to have >>>> the mask '-rw-rw-r--': >>>> >>>> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done | sed >>>> -e '/-rw-rw-r--/d' >>>> $ >>>> >>>> Regarding properties files, here is the exhaustive list of properties >>>> that RPM packaging has modified the privileges of: >>>> >>>> appclient/configuration/logging.properties rw------- >>>> domain/configuration/application-roles.properties rw------- >>>> domain/configuration/default-server-logging.properties rw------- >>>> domain/configuration/logging.properties rw------- >>>> domain/configuration/mgmt-groups.properties rw------- >>>> standalone/configuration/application-roles.properties rw------- >>>> standalone/configuration/logging.properties rw------- >>>> standalone/configuration/mgmt-groups.properties rw------- >>>> >>>> If I compare that with the content of the extract zip (same fresh >>>> built as above), I can see that 4 files are not having the same mask >>>> (rw------): >>>> >>>> $ for file in $(cut -f1 -d\ ../../../list-props-files.txt ); do ls -l >>>> $file ; done >>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov. 11:41 >>>> appclient/configuration/logging.properties >>>> -rw-------. 1 rpelisse rpelisse 710 30 nov. 11:41 >>>> domain/configuration/application-roles.properties >>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov. 11:41 >>>> domain/configuration/default-server-logging.properties >>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov. 11:41 >>>> domain/configuration/logging.properties >>>> -rw-------. 1 rpelisse rpelisse 669 30 nov. 11:41 >>>> domain/configuration/mgmt-groups.properties >>>> -rw-------. 1 rpelisse rpelisse 711 30 nov. 11:41 >>>> standalone/configuration/application-roles.properties >>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov. 11:41 >>>> standalone/configuration/logging.properties >>>> -rw-------. 1 rpelisse rpelisse 669 30 nov. 11:41 >>>> standalone/configuration/mgmt-groups.properties >>>> >>>> Now, as you said, those files privileges are indeed fine-grained, so >>>> maybe we can push back to people making the RPM for them to NOT change the >>>> following files privileges: >>>> >>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov. 11:41 >>>> appclient/configuration/logging.properties >>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov. 11:41 >>>> domain/configuration/default-server-logging.properties >>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov. 11:41 >>>> domain/configuration/logging.properties >>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov. 11:41 >>>> standalone/configuration/logging.properties >>>> >>>> However, I don't see the value of letting those files accessible >>>> either group member or any user on the system, but maybe we can make the >>>> argument they should. But the write privileges for group member sounds >>>> wrong to me. >>>> >>>> Also, I'm puzzled Brian and I are seeing different things - am I >>>> looking at the correct zipfile here ? >>>> >>>> Note: You also mention the module.xml - as far as I can see from the >>>> diff provided with issue JBEAP-12374, I don't see any issue with privileges >>>> regarding those files, so we can remove them of the discussion. The only >>>> changes we need to discuss is removing the 'write' privileges' for the >>>> group on jars, reducing the scope of permissions on (some) folders, and >>>> privileges on (some) properties files. So, module.xml are out of the scope. >>>> >>>> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> Seems I forgot to "Reply to All" yesterday. The following was meant >>>>> to be sent to wildfly-dev. >>>>> >>>>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry < >>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>> >>>>>> Before getting into the specifics, first a general note re: perms. >>>>>> >>>>>> Our general permission set for is rwxr-xr-x for directories and >>>>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up. >>>>>> ;). Otherwise I think any deviation from that we should justify. Not that >>>>>> deviations are wrong, just that they need to have a reason. >>>>>> >>>>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> Well, the diff is between the RPM and the zipfile is pretty long, >>>>>>> but it boils down to the 3 set of differences I've pointed out on >>>>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574> >>>>>>> >>>>>>> - *.properties and .jar* files are associated with the mask >>>>>>> rw-rw-r-- giving access to it to any other users and allowing group member >>>>>>> to modify the file - the RPM distribution fixes that by removing the write >>>>>>> privileges for the group (rw-r--r--). I personnaly don't see the value of >>>>>>> letting the group members modify those files, I just can see how this could >>>>>>> be exploited, so I would say it falls into "clearly wrong and not our >>>>>>> intent". A case might be made for the .properties files, but for jars file >>>>>>> I really don't see a valid use case (unless of course, any of you know one) >>>>>>> ; >>>>>>> >>>>>>> There are a few different things here, so let's deal with them >>>>>> separately. >>>>>> >>>>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as >>>>>> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I >>>>>> don't see why they should vary from the general standard. And the >>>>>> module.xml file should be consistent, since there's not much point in >>>>>> locking people from touching jars but letting them change what jars get >>>>>> loaded. >>>>>> >>>>>> For properties files, let's consider them on a more fine-grained >>>>>> basis. For example, the properties files used by the security realms have >>>>>> different kinds of data than logging.properties does. >>>>>> >>>>>> The perms on the security realm property files are rw-------, not >>>>>> rw-rw-r--. >>>>>> >>>>>> The logging.properties files are rw-r--r-- which is consistent with >>>>>> the domain|host|standalone.xml files and with the general standard. >>>>>> >>>>>> >>>>>>> >>>>>>> - >>>>>>> - *some directories* like 'domain/tmp/auth' have too >>>>>>> restrictive mask like rwx------ and RPMS to turned them into rwxrwxr-x >>>>>>> (that I don't really agree with) and >>>>>>> >>>>>>> >>>>>>> - *other directories*, likes 'domain' have again a too >>>>>>> permissive mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make >>>>>>> senses. >>>>>>> >>>>>>> In the unzip I see these directories as rwxr-xr-x, which I think is >>>>>> fine. >>>>>> >>>>>> Are you concerned with any other directories besides >>>>>> $JBOSS_HOME/domain and $JBOSS_HOME/standalone? >>>>>> >>>>>>> So we need to find an agreement on those three items, and then see >>>>>>> how we proceed to implement the fix (if needed). >>>>>>> >>>>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry < >>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> I think we need to start with the assumption that the permissions >>>>>>>> we have in the zip are the way they are for a reason and evaluate possible >>>>>>>> changes based on discussion here of each type of change. Maybe the RPM >>>>>>>> settings are better, maybe they are not. Or maybe they are better but the >>>>>>>> improvement is not worth the disruption a change may cause to our end >>>>>>>> users, who may rely on the current zip settings. Or maybe what we have in >>>>>>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll >>>>>>>> probably see a little of each category, although hopefully some changes for >>>>>>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :) >>>>>>>> >>>>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse < >>>>>>>> belaran(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> As reported on JBEAP-12374[1], there is some discrepancies >>>>>>>>> between the ZIP file we provided for Widlfy/EAP and the RPM generate. Most >>>>>>>>> of those discrepancies - or the most relevant ones, are some fine tuning >>>>>>>>> performed on the (POSIX) privileges (things such as removing the write >>>>>>>>> privilege for member of the same group as the owner of the file). >>>>>>>>> >>>>>>>>> I've looked into this and because those files are produced by our >>>>>>>>> own Maven plugin (as part of wildfly-build-tools), we can not simply modify >>>>>>>>> the assembly.xml. Which actually is probably for the best, as it would made >>>>>>>>> the assembly file quite cumbersome. >>>>>>>>> >>>>>>>>> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, >>>>>>>>> but when I reported the problem on WFLY-9574[3], Brian suggested I started >>>>>>>>> a discussion here. So does anyone have a (strong) opinion about this issue >>>>>>>>> and/or how to resolve it ? :) >>>>>>>>> >>>>>>>>> (For the record, I do think it is best to fix the privileges to >>>>>>>>> follow what the RPM does for us for now, but if you feel this issue should >>>>>>>>> not be addressed, and dev- the issue, I'm certainly not opposed to it >>>>>>>>> either). >>>>>>>>> >>>>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374 >>>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40 >>>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> wildfly-dev mailing list >>>>>>>>> wildfly-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Brian Stansberry >>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>> Red Hat >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Brian Stansberry >>>>>> Manager, Senior Principal Software Engineer >>>>>> Red Hat >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Manager, Senior Principal Software Engineer >>>>> Red Hat >>>>> >>>> >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Manager, Senior Principal Software Engineer >>> Red Hat >>> >> >> >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> Red Hat >> > > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat

I personally don't have any strong opinions on what the permissions should be. However as I said before it should definitely not be the provisioning plugin that sets these permissions. If they need to be different we need to change them in the feature pack. On Mon, Dec 11, 2017 at 4:47 AM, Romain Pelisse <belaran(a)redhat.com <mailto:belaran@redhat.com>> wrote: Hi all, Not too much involvement except from Brian and I :) - sadly, we cannot move forward on this topic without a minimum of consensus. If you don't to participate, can you at least reply "+1 Brian" (if you think we should NOT try to change the current behavior") or "+1 Romain" (if you think we should address this issue somehow). (please don't vote on the PR I've proposed, it's just a proposal on HOW we could do it - here I want to assert IF we want to do it, not voting on the "how"). On Wed, Dec 6, 2017 at 6:05 PM, Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse <belaran(a)redhat.com <mailto:belaran@redhat.com>> wrote: Hi Brian (and all), I honestly understand your resistance, and I'm completely fine if we end up closing this all issue as WONTDO or REJECTED. I just do want to have a discussion about it and come back with clear reasons and motivations for changing or not the privileges of each of those files. Thanks for doing this! There have been a number of issues filed over the last year or so on this general topic so I'm very happy to see them getting addressed here via the WildFly community. Most of the issues I've been talking about are JBEAP issues in JIRA, which is fine, but the best way to get this solid is to get WildFly the way we want it first. Even on the config file read perms thing I mentioned in my last post, I'm personally resistant to changing it, but my biggest resistance is to doing that without a full community discussion. Given that we see different things on our local setup, I think the best will be to use a build on a CI Server and works from what we see there. Is there an easy way for me to clone a job building Wildfly and tweak it on some (publicly) accessible instance ? https://developer.jboss.org/thread/224262 <https://developer.jboss.org/thread/224262> describes how to get a zip built from a daily CI job. If anyone has any insights on this, please speak up! On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: A slightly different topic, related to the "logging.properties/xml config file" topic is whether these files should be world and/or group readable. Changing this has been proposed in the past on the EAP side, primarily based on the argument that users could put sensitive data in these files. This thread seems like a good time to debate this a bit in community. I've resisted that primarily on the basis of: 1) These files or those similarly used have had these perms as far back as I can find in JBoss AS. So the odds that some people are relying upon those perms is fairly high and we need to assume a change would be a breaking change for some people. 2) Other software I've looked at like Tomcat and httpd have similar permission schemes to what we have for their config files, which can also potentially include sensitive data. 3) We provide facilities like the vault or elytron credential store refs for keeping sensitive data out of the config files. On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: Thanks, Romain. Re: what the actual permissions are, FWIW I get what I see on both my macbook and my Fedora 27 machine, both when unzipping the actual 11.0.0.Final and when unzipping the result of a build of master, and both with and without the -Prelease -Pjboss-release args to maven that we include when doing actual releases. Unzipping the zip in build/target doesn't include the jars of course. So it sounds like we need input from others. Re: modules.xml, if you are seeing those as rw-r--r-- as well, then +1 to ignoring them in further discussion. Re: logging.properties, those serve a very similar conceptual role to the standalone|host|domain.xml files so I see no reason for them to have different perms. However, you and I are getting different results, where you report them as group writable and I don't. What do you see for the xml config files? Re: RPM changing to match WildFly, that's an EAP discussion, so that can be taken up elsewhere once we have WildFly the way we want it. On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran(a)redhat.com <mailto:belaran@redhat.com>> wrote: Hi Brian and all, err, my own observation differs from yours. I've rebuild Wildfly from the last content of the master branch and get the same privileges on the jboss-modules.jar (so -rw-rw-r-- and not as you are seeing rwxr--r--). Same with the domain folder, which turns out on my local system associated to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a transcript of what I did - maybe you can spot why our results differs so much. $ git show commit 46e119c65d9e32bc0ec69f3933267fece959ed3f Merge: 051f080 c7d9075 Author: Kabir Khan <kkhan(a)redhat.com <mailto:kkhan@redhat.com>> Date:   Tue Nov 28 17:46:40 2017 +0000     Merge pull request #10669 from praxeo/WFLY-9284     WFLY-9284 Correct MVN env variable to mvnw.cmd $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d wildfly-12.zip ... $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov.  11:41 wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/ -d drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.  11:41 wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/ Checking all the jars in the distribution, they all appears to have the mask '-rw-rw-r--': $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done | sed -e '/-rw-rw-r--/d' $ Regarding properties files, here is the exhaustive list of properties that RPM packaging has modified the privileges of: appclient/configuration/logging.properties rw------- domain/configuration/application-roles.properties rw------- domain/configuration/default-server-logging.properties rw------- domain/configuration/logging.properties rw------- domain/configuration/mgmt-groups.properties rw------- standalone/configuration/application-roles.properties rw------- standalone/configuration/logging.properties rw------- standalone/configuration/mgmt-groups.properties rw------- If I compare that with the content of the extract zip (same fresh built as above), I can see that 4 files are not having the same mask (rw------): $ for file in $(cut -f1 -d\ ../../../list-props-files.txt ); do ls -l $file ; done -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41 appclient/configuration/logging.properties -rw-------. 1 rpelisse rpelisse 710 30 nov.  11:41 domain/configuration/application-roles.properties -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41 domain/configuration/default-server-logging.properties -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41 domain/configuration/logging.properties -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41 domain/configuration/mgmt-groups.properties -rw-------. 1 rpelisse rpelisse 711 30 nov.  11:41 standalone/configuration/application-roles.properties -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41 standalone/configuration/logging.properties -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41 standalone/configuration/mgmt-groups.properties Now, as you said, those files privileges are indeed fine-grained, so maybe we can push back to people making the RPM for them to NOT change the following files privileges: -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41 appclient/configuration/logging.properties -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41 domain/configuration/default-server-logging.properties -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41 domain/configuration/logging.properties -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41 standalone/configuration/logging.properties However, I don't see the value of letting those files accessible either group member or any user on the system, but maybe we can make the argument they should. But the write privileges for group member sounds wrong to me. Also, I'm puzzled Brian and I are seeing different things - am I looking at the correct zipfile here ? Note: You also mention the module.xml - as far as I can see from the diff provided with issue JBEAP-12374, I don't see any issue with privileges regarding those files, so we can remove them of the discussion. The only changes we need to discuss is removing the 'write' privileges' for the group on jars, reducing the scope of permissions on (some) folders, and privileges on (some) properties files. So, module.xml are out of the scope. On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: Seems I forgot to "Reply to All" yesterday. The following was meant to be sent to wildfly-dev. On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: Before getting into the specifics, first a general note re: perms. Our general permission set for is rwxr-xr-x for directories and rwxr--r-- for files. If someone thinks that's wrong in general; speak up. ;). Otherwise I think any deviation from that we should justify. Not that deviations are wrong, just that they need to have a reason. On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran(a)redhat.com <mailto:belaran@redhat.com>> wrote: Well, the diff is between the RPM and the zipfile is pretty long, but it boils down to the 3 set of differences I've pointed out on WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574> * *.properties and .jar* files are associated with the mask rw-rw-r-- giving access to it to any other users and allowing group member to modify the file - the RPM distribution fixes that by removing the write privileges for the group (rw-r--r--). I personnaly don't see the value of letting the group members modify those files, I just can see how this could be exploited, so I would say it falls into "clearly wrong and not our intent". A case might be made for the .properties files, but for jars file I really don't see a valid use case (unless of course, any of you know one) ; There are a few different things here, so let's deal with them separately. For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I don't see why they should vary from the general standard. And the module.xml file should be consistent, since there's not much point in locking people from touching jars but letting them change what jars get loaded. For properties files, let's consider them on a more fine-grained basis. For example, the properties files used by the security realms have different kinds of data than logging.properties does. The perms on the security realm property files are rw-------, not rw-rw-r--. The logging.properties files are rw-r--r-- which is consistent with the domain|host|standalone.xml files and with the general standard. * * *some directories* like 'domain/tmp/auth' have too restrictive mask like rwx------ and RPMS to turned them into rwxrwxr-x (that I don't really agree with) and * *other directories*, likes 'domain' have again a too permissive mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make senses. In the unzip I see these directories as rwxr-xr-x, which I think is fine. Are you concerned with any other directories besides $JBOSS_HOME/domain and $JBOSS_HOME/standalone? So we need to find an agreement on those three items, and then see how we proceed to implement the fix (if needed). On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: I think we need to start with the assumption that the permissions we have in the zip are the way they are for a reason and evaluate possible changes based on discussion here of each type of change. Maybe the RPM settings are better, maybe they are not. Or maybe they are better but the improvement is not worth the disruption a change may cause to our end users, who may rely on the current zip settings. Or maybe what we have in the zip is clearly wrong and doesn't follow our own intent. I expect we'll probably see a little of each category, although hopefully some changes for WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :) On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <belaran(a)redhat.com <mailto:belaran@redhat.com>> wrote: Hi, As reported on JBEAP-12374[1], there is some discrepancies between the ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those discrepancies - or the most relevant ones, are some fine tuning performed on the (POSIX) privileges (things such as removing the write privilege for member of the same group as the owner of the file). I've looked into this and because those files are produced by our own Maven plugin (as part of wildfly-build-tools), we can not simply modify the assembly.xml. Which actually is probably for the best, as it would made the assembly file quite cumbersome. Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, but when I reported the problem on WFLY-9574[3], Brian suggested I started a discussion here. So does anyone have a (strong) opinion about this issue and/or how to resolve it ? :) (For the record, I do think it is best to fix the privileges to follow what the RPM does for us for now, but if you feel this issue should not be addressed, and dev- the issue, I'm certainly not opposed to it either). [1] https://issues.jboss.org/browse/JBEAP-12374 <https://issues.jboss.org/browse/JBEAP-12374> [2] https://github.com/wildfly/wildfly-build-tools/pull/40 <https://github.com/wildfly/wildfly-build-tools/pull/40> [3] https://issues.jboss.org/browse/WFLY-9574 <https://issues.jboss.org/browse/WFLY-9574> _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev> -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev> -- James R. Perkins JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

That means the packaging tool has to know about all the files it consumes. That would make the feature pack concept irrelevant. There could be a reason the feature pack set specific permissions on a file and the provisioning tool should honor that. It shouldn't be making assumptions. Especially if that assumption is determined by a file extension. On Tue, Dec 12, 2017 at 12:20 AM, Carlo de Wolf <cdewolf(a)redhat.com&gt; wrote: > If any target platform needs more restrictive permissions, those need to > apply to all deliverables (whether it is ZIP or RPMs). > > Carlo > > > On 11-12-17 23:28, James Perkins wrote: > > I personally don't have any strong opinions on what the permissions > should be. However as I said before it should definitely not be the > provisioning plugin that sets these permissions. If they need to be > different we need to change them in the feature pack. > > On Mon, Dec 11, 2017 at 4:47 AM, Romain Pelisse <belaran(a)redhat.com&gt; > wrote: > >> Hi all, >> >> Not too much involvement except from Brian and I :) - sadly, we cannot >> move forward on this topic without a minimum of consensus. If you don't to >> participate, can you at least reply "+1 Brian" (if you think we should NOT >> try to change the current behavior") or "+1 Romain" (if you think we should >> address this issue somehow). >> >> (please don't vote on the PR I've proposed, it's just a proposal on HOW >> we could do it - here I want to assert IF we want to do it, not voting on >> the "how"). >> >> On Wed, Dec 6, 2017 at 6:05 PM, Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse <belaran(a)redhat.com&gt; >>> wrote: >>> >>>> Hi Brian (and all), >>>> >>>> I honestly understand your resistance, and I'm completely fine if we >>>> end up closing this all issue as WONTDO or REJECTED. I just do want to have >>>> a discussion about it and come back with clear reasons and motivations for >>>> changing or not the privileges of each of those files. >>>> >>> >>> Thanks for doing this! There have been a number of issues filed over >>> the last year or so on this general topic so I'm very happy to see them >>> getting addressed here via the WildFly community. Most of the issues I've >>> been talking about are JBEAP issues in JIRA, which is fine, but the best >>> way to get this solid is to get WildFly the way we want it first. >>> >>> Even on the config file read perms thing I mentioned in my last post, >>> I'm personally resistant to changing it, but my biggest resistance is to >>> doing that without a full community discussion. >>> >>> >>>> Given that we see different things on our local setup, I think the >>>> best will be to use a build on a CI Server and works from what we see >>>> there. Is there an easy way for me to clone a job building Wildfly and >>>> tweak it on some (publicly) accessible instance ? >>>> >>> >>> https://developer.jboss.org/thread/224262 describes how to get a zip >>> built from a daily CI job. >>> >>> If anyone has any insights on this, please speak up! >>> >>> >>>> >>>> >>>> On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> A slightly different topic, related to the "logging.properties/xml >>>>> config file" topic is whether these files should be world and/or group >>>>> readable. >>>>> >>>>> Changing this has been proposed in the past on the EAP side, >>>>> primarily based on the argument that users could put sensitive data in >>>>> these files. This thread seems like a good time to debate this a bit in >>>>> community. >>>>> >>>>> I've resisted that primarily on the basis of: >>>>> >>>>> 1) These files or those similarly used have had these perms as far >>>>> back as I can find in JBoss AS. So the odds that some people are relying >>>>> upon those perms is fairly high and we need to assume a change would be a >>>>> breaking change for some people. >>>>> >>>>> 2) Other software I've looked at like Tomcat and httpd have similar >>>>> permission schemes to what we have for their config files, which can also >>>>> potentially include sensitive data. >>>>> >>>>> 3) We provide facilities like the vault or elytron credential store >>>>> refs for keeping sensitive data out of the config files. >>>>> >>>>> >>>>> On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry < >>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>> >>>>>> Thanks, Romain. >>>>>> >>>>>> Re: what the actual permissions are, FWIW I get what I see on both >>>>>> my macbook and my Fedora 27 machine, both when unzipping the actual >>>>>> 11.0.0.Final and when unzipping the result of a build of master, and both >>>>>> with and without the -Prelease -Pjboss-release args to maven that we >>>>>> include when doing actual releases. Unzipping the zip in build/target >>>>>> doesn't include the jars of course. >>>>>> >>>>>> So it sounds like we need input from others. >>>>>> >>>>>> Re: modules.xml, if you are seeing those as rw-r--r-- as well, then >>>>>> +1 to ignoring them in further discussion. >>>>>> >>>>>> Re: logging.properties, those serve a very similar conceptual role >>>>>> to the standalone|host|domain.xml files so I see no reason for them to have >>>>>> different perms. However, you and I are getting different results, where >>>>>> you report them as group writable and I don't. What do you see for the xml >>>>>> config files? >>>>>> >>>>>> Re: RPM changing to match WildFly, that's an EAP discussion, so that >>>>>> can be taken up elsewhere once we have WildFly the way we want it. >>>>>> >>>>>> >>>>>> On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> Hi Brian and all, >>>>>>> >>>>>>> err, my own observation differs from yours. I've rebuild Wildfly >>>>>>> from the last content of the master branch and get the same privileges on >>>>>>> the jboss-modules.jar (so -rw-rw-r-- and not as you are seeing rwxr--r--). >>>>>>> Same with the domain folder, which turns out on my local system associated >>>>>>> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a >>>>>>> transcript of what I did - maybe you can spot why our results differs so >>>>>>> much. >>>>>>> >>>>>>> $ git show >>>>>>> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f >>>>>>> Merge: 051f080 c7d9075 >>>>>>> Author: Kabir Khan <kkhan(a)redhat.com&gt; >>>>>>> Date: Tue Nov 28 17:46:40 2017 +0000 >>>>>>> >>>>>>> Merge pull request #10669 from praxeo/WFLY-9284 >>>>>>> >>>>>>> WFLY-9284 Correct MVN env variable to mvnw.cmd >>>>>>> >>>>>>> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d >>>>>>> wildfly-12.zip >>>>>>> ... >>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0. >>>>>>> Alpha1-SNAPSHOT/jboss-modules.jar >>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov. 11:41 >>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar >>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/ -d >>>>>>> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov. 11:41 >>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/ >>>>>>> >>>>>>> Checking all the jars in the distribution, they all appears to have >>>>>>> the mask '-rw-rw-r--': >>>>>>> >>>>>>> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done | >>>>>>> sed -e '/-rw-rw-r--/d' >>>>>>> $ >>>>>>> >>>>>>> Regarding properties files, here is the exhaustive list of >>>>>>> properties that RPM packaging has modified the privileges of: >>>>>>> >>>>>>> appclient/configuration/logging.properties rw------- >>>>>>> domain/configuration/application-roles.properties rw------- >>>>>>> domain/configuration/default-server-logging.properties rw------- >>>>>>> domain/configuration/logging.properties rw------- >>>>>>> domain/configuration/mgmt-groups.properties rw------- >>>>>>> standalone/configuration/application-roles.properties rw------- >>>>>>> standalone/configuration/logging.properties rw------- >>>>>>> standalone/configuration/mgmt-groups.properties rw------- >>>>>>> >>>>>>> If I compare that with the content of the extract zip (same fresh >>>>>>> built as above), I can see that 4 files are not having the same mask >>>>>>> (rw------): >>>>>>> >>>>>>> $ for file in $(cut -f1 -d\ ../../../list-props-files.txt ); do ls >>>>>>> -l $file ; done >>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov. 11:41 >>>>>>> appclient/configuration/logging.properties >>>>>>> -rw-------. 1 rpelisse rpelisse 710 30 nov. 11:41 >>>>>>> domain/configuration/application-roles.properties >>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov. 11:41 >>>>>>> domain/configuration/default-server-logging.properties >>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov. 11:41 >>>>>>> domain/configuration/logging.properties >>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov. 11:41 >>>>>>> domain/configuration/mgmt-groups.properties >>>>>>> -rw-------. 1 rpelisse rpelisse 711 30 nov. 11:41 >>>>>>> standalone/configuration/application-roles.properties >>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov. 11:41 >>>>>>> standalone/configuration/logging.properties >>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov. 11:41 >>>>>>> standalone/configuration/mgmt-groups.properties >>>>>>> >>>>>>> Now, as you said, those files privileges are indeed fine-grained, >>>>>>> so maybe we can push back to people making the RPM for them to NOT change >>>>>>> the following files privileges: >>>>>>> >>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov. 11:41 >>>>>>> appclient/configuration/logging.properties >>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov. 11:41 >>>>>>> domain/configuration/default-server-logging.properties >>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov. 11:41 >>>>>>> domain/configuration/logging.properties >>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov. 11:41 >>>>>>> standalone/configuration/logging.properties >>>>>>> >>>>>>> However, I don't see the value of letting those files accessible >>>>>>> either group member or any user on the system, but maybe we can make the >>>>>>> argument they should. But the write privileges for group member sounds >>>>>>> wrong to me. >>>>>>> >>>>>>> Also, I'm puzzled Brian and I are seeing different things - am I >>>>>>> looking at the correct zipfile here ? >>>>>>> >>>>>>> Note: You also mention the module.xml - as far as I can see from >>>>>>> the diff provided with issue JBEAP-12374, I don't see any issue with >>>>>>> privileges regarding those files, so we can remove them of the discussion. >>>>>>> The only changes we need to discuss is removing the 'write' privileges' for >>>>>>> the group on jars, reducing the scope of permissions on (some) folders, and >>>>>>> privileges on (some) properties files. So, module.xml are out of the scope. >>>>>>> >>>>>>> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry < >>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> Seems I forgot to "Reply to All" yesterday. The following was >>>>>>>> meant to be sent to wildfly-dev. >>>>>>>> >>>>>>>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry < >>>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>>> Before getting into the specifics, first a general note re: perms. >>>>>>>>> >>>>>>>>> Our general permission set for is rwxr-xr-x for directories and >>>>>>>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up. >>>>>>>>> ;). Otherwise I think any deviation from that we should justify. Not that >>>>>>>>> deviations are wrong, just that they need to have a reason. >>>>>>>>> >>>>>>>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse < >>>>>>>>> belaran(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> Well, the diff is between the RPM and the zipfile is pretty >>>>>>>>>> long, but it boils down to the 3 set of differences I've pointed out on >>>>>>>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574> >>>>>>>>>> >>>>>>>>>> - *.properties and .jar* files are associated with the mask >>>>>>>>>> rw-rw-r-- giving access to it to any other users and allowing group member >>>>>>>>>> to modify the file - the RPM distribution fixes that by removing the write >>>>>>>>>> privileges for the group (rw-r--r--). I personnaly don't see the value of >>>>>>>>>> letting the group members modify those files, I just can see how this could >>>>>>>>>> be exploited, so I would say it falls into "clearly wrong and not our >>>>>>>>>> intent". A case might be made for the .properties files, but for jars file >>>>>>>>>> I really don't see a valid use case (unless of course, any of you know one) >>>>>>>>>> ; >>>>>>>>>> >>>>>>>>>> There are a few different things here, so let's deal with them >>>>>>>>> separately. >>>>>>>>> >>>>>>>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them >>>>>>>>> as rwxr--r--. Which seems correct to me. In case I'm seeing something >>>>>>>>> wrong, I don't see why they should vary from the general standard. And the >>>>>>>>> module.xml file should be consistent, since there's not much point in >>>>>>>>> locking people from touching jars but letting them change what jars get >>>>>>>>> loaded. >>>>>>>>> >>>>>>>>> For properties files, let's consider them on a more fine-grained >>>>>>>>> basis. For example, the properties files used by the security realms have >>>>>>>>> different kinds of data than logging.properties does. >>>>>>>>> >>>>>>>>> The perms on the security realm property files are rw-------, not >>>>>>>>> rw-rw-r--. >>>>>>>>> >>>>>>>>> The logging.properties files are rw-r--r-- which is consistent >>>>>>>>> with the domain|host|standalone.xml files and with the general standard. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> - >>>>>>>>>> - *some directories* like 'domain/tmp/auth' have too >>>>>>>>>> restrictive mask like rwx------ and RPMS to turned them into rwxrwxr-x >>>>>>>>>> (that I don't really agree with) and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - *other directories*, likes 'domain' have again a too >>>>>>>>>> permissive mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make >>>>>>>>>> senses. >>>>>>>>>> >>>>>>>>>> In the unzip I see these directories as rwxr-xr-x, which I think >>>>>>>>> is fine. >>>>>>>>> >>>>>>>>> Are you concerned with any other directories besides >>>>>>>>> $JBOSS_HOME/domain and $JBOSS_HOME/standalone? >>>>>>>>> >>>>>>>>>> So we need to find an agreement on those three items, and then >>>>>>>>>> see how we proceed to implement the fix (if needed). >>>>>>>>>> >>>>>>>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry < >>>>>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>>>>> >>>>>>>>>>> I think we need to start with the assumption that the >>>>>>>>>>> permissions we have in the zip are the way they are for a reason and >>>>>>>>>>> evaluate possible changes based on discussion here of each type of change. >>>>>>>>>>> Maybe the RPM settings are better, maybe they are not. Or maybe they are >>>>>>>>>>> better but the improvement is not worth the disruption a change may cause >>>>>>>>>>> to our end users, who may rely on the current zip settings. Or maybe what >>>>>>>>>>> we have in the zip is clearly wrong and doesn't follow our own intent. I >>>>>>>>>>> expect we'll probably see a little of each category, although hopefully >>>>>>>>>>> some changes for WF 11 removed the "clearly wrong and doesn't follow our >>>>>>>>>>> intent" cases. :) >>>>>>>>>>> >>>>>>>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse < >>>>>>>>>>> belaran(a)redhat.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> As reported on JBEAP-12374[1], there is some discrepancies >>>>>>>>>>>> between the ZIP file we provided for Widlfy/EAP and the RPM generate. Most >>>>>>>>>>>> of those discrepancies - or the most relevant ones, are some fine tuning >>>>>>>>>>>> performed on the (POSIX) privileges (things such as removing the write >>>>>>>>>>>> privilege for member of the same group as the owner of the file). >>>>>>>>>>>> >>>>>>>>>>>> I've looked into this and because those files are produced by >>>>>>>>>>>> our own Maven plugin (as part of wildfly-build-tools), we can not simply >>>>>>>>>>>> modify the assembly.xml. Which actually is probably for the best, as it >>>>>>>>>>>> would made the assembly file quite cumbersome. >>>>>>>>>>>> >>>>>>>>>>>> Anyhow, I've worked on a proposal[2] for the >>>>>>>>>>>> wildfly-build-tools, but when I reported the problem on WFLY-9574[3], Brian >>>>>>>>>>>> suggested I started a discussion here. So does anyone have a (strong) >>>>>>>>>>>> opinion about this issue and/or how to resolve it ? :) >>>>>>>>>>>> >>>>>>>>>>>> (For the record, I do think it is best to fix the privileges >>>>>>>>>>>> to follow what the RPM does for us for now, but if you feel this issue >>>>>>>>>>>> should not be addressed, and dev- the issue, I'm certainly not opposed to >>>>>>>>>>>> it either). >>>>>>>>>>>> >>>>>>>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374 >>>>>>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40 >>>>>>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574 >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> wildfly-dev mailing list >>>>>>>>>>>> wildfly-dev(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Brian Stansberry >>>>>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>>>>> Red Hat >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Brian Stansberry >>>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>>> Red Hat >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Brian Stansberry >>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>> Red Hat >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Brian Stansberry >>>>>> Manager, Senior Principal Software Engineer >>>>>> Red Hat >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Manager, Senior Principal Software Engineer >>>>> Red Hat >>>>> >>>> >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Manager, Senior Principal Software Engineer >>> Red Hat >>> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > James R. Perkins > JBoss by Red Hat > > > _______________________________________________ > wildfly-dev mailing listwildfly-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- James R. Perkins JBoss by Red Hat

Hi all, I did some more digging into this issue, trying to understand why Brian and I are having different results - especially on the privileges associated to the jars. It turns out that the wildfly builds for 10,11 and 12 are indeed associating the proper privileges to jars ( so -rw-r--r--.), but the build of EAP 7.1 are creating an archive with different set of priviliges (-rw-rw-r--) for jars... Same thing with the directory privileges. The 'domain' directory produced by all 3 final version of Wildfly (10,11 and 12) is associated to drwxr-xr-x and not drwxrwxr-x (as the EAP 7 builds produces): I've a small script to check and the output clearly shows this discrepencies: $ ./show-privileges.sh Extracting archive into /tmp/tmp.Aufm1F6d2h...Done. -rw-r--r--. 1 rpelisse rpelisse 364930 29 janv. 2016 /tmp/tmp.Aufm1F6d2h/wildfly-10.0.0.Final/jboss-modules.jar drwxr-xr-x. 5 rpelisse rpelisse 100 29 janv. 2016 /tmp/tmp.Aufm1F6d2h/wildfly-10.0.0.Final/domain/ Done. $ export ZIP_FILE=jboss-eap-7.1.zip $ ./show-privileges.sh Extracting archive into /tmp/tmp.sErv7wRwoS...Done. -rw-rw-r--. 1 rpelisse rpelisse 401354 8 nov. 20:47 /tmp/tmp.sErv7wRwoS/jboss-eap-7.1/jboss-modules.jar drwxrwxr-x. 5 rpelisse rpelisse 100 8 nov. 20:47 /tmp/tmp.sErv7wRwoS/jboss-eap-7.1/domain/ Done. I am going to investigate why EAP builds behaves differently than Wildlfy (but it does not really concern this mailing list). Thus, I consider this topic closed for upstream (at least for now, once EAP builds behavior is aligned with the one of Wildfly we can see if there is some more discrepencies to be worried about). On Tue, Dec 12, 2017 at 9:12 PM, James Perkins <jperkins(a)redhat.com&gt; wrote: > My apologies after rereading the comment I think you're just saying > permissions need to be consistent across all deliverables which I agree > with. Sorry for the confusion. > > On Tue, Dec 12, 2017 at 8:47 AM, James Perkins <jperkins(a)redhat.com&gt; > wrote: > >> That means the packaging tool has to know about all the files it >> consumes. That would make the feature pack concept irrelevant. There could >> be a reason the feature pack set specific permissions on a file and the >> provisioning tool should honor that. It shouldn't be making assumptions. >> Especially if that assumption is determined by a file extension. >> >> On Tue, Dec 12, 2017 at 12:20 AM, Carlo de Wolf <cdewolf(a)redhat.com&gt; >> wrote: >> >>> If any target platform needs more restrictive permissions, those need >>> to apply to all deliverables (whether it is ZIP or RPMs). >>> >>> Carlo >>> >>> >>> On 11-12-17 23:28, James Perkins wrote: >>> >>> I personally don't have any strong opinions on what the permissions >>> should be. However as I said before it should definitely not be the >>> provisioning plugin that sets these permissions. If they need to be >>> different we need to change them in the feature pack. >>> >>> On Mon, Dec 11, 2017 at 4:47 AM, Romain Pelisse <belaran(a)redhat.com&gt; >>> wrote: >>> >>>> Hi all, >>>> >>>> Not too much involvement except from Brian and I :) - sadly, we cannot >>>> move forward on this topic without a minimum of consensus. If you don't to >>>> participate, can you at least reply "+1 Brian" (if you think we should NOT >>>> try to change the current behavior") or "+1 Romain" (if you think we should >>>> address this issue somehow). >>>> >>>> (please don't vote on the PR I've proposed, it's just a proposal on >>>> HOW we could do it - here I want to assert IF we want to do it, not voting >>>> on the "how"). >>>> >>>> On Wed, Dec 6, 2017 at 6:05 PM, Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse <belaran(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> Hi Brian (and all), >>>>>> >>>>>> I honestly understand your resistance, and I'm completely fine if we >>>>>> end up closing this all issue as WONTDO or REJECTED. I just do want to have >>>>>> a discussion about it and come back with clear reasons and motivations for >>>>>> changing or not the privileges of each of those files. >>>>>> >>>>> >>>>> Thanks for doing this! There have been a number of issues filed over >>>>> the last year or so on this general topic so I'm very happy to see them >>>>> getting addressed here via the WildFly community. Most of the issues I've >>>>> been talking about are JBEAP issues in JIRA, which is fine, but the best >>>>> way to get this solid is to get WildFly the way we want it first. >>>>> >>>>> Even on the config file read perms thing I mentioned in my last post, >>>>> I'm personally resistant to changing it, but my biggest resistance is to >>>>> doing that without a full community discussion. >>>>> >>>>> >>>>>> Given that we see different things on our local setup, I think the >>>>>> best will be to use a build on a CI Server and works from what we see >>>>>> there. Is there an easy way for me to clone a job building Wildfly and >>>>>> tweak it on some (publicly) accessible instance ? >>>>>> >>>>> >>>>> https://developer.jboss.org/thread/224262 describes how to get a zip >>>>> built from a daily CI job. >>>>> >>>>> If anyone has any insights on this, please speak up! >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry < >>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>> >>>>>>> A slightly different topic, related to the "logging.properties/xml >>>>>>> config file" topic is whether these files should be world and/or group >>>>>>> readable. >>>>>>> >>>>>>> Changing this has been proposed in the past on the EAP side, >>>>>>> primarily based on the argument that users could put sensitive data in >>>>>>> these files. This thread seems like a good time to debate this a bit in >>>>>>> community. >>>>>>> >>>>>>> I've resisted that primarily on the basis of: >>>>>>> >>>>>>> 1) These files or those similarly used have had these perms as far >>>>>>> back as I can find in JBoss AS. So the odds that some people are relying >>>>>>> upon those perms is fairly high and we need to assume a change would be a >>>>>>> breaking change for some people. >>>>>>> >>>>>>> 2) Other software I've looked at like Tomcat and httpd have similar >>>>>>> permission schemes to what we have for their config files, which can also >>>>>>> potentially include sensitive data. >>>>>>> >>>>>>> 3) We provide facilities like the vault or elytron credential store >>>>>>> refs for keeping sensitive data out of the config files. >>>>>>> >>>>>>> >>>>>>> On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry < >>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> Thanks, Romain. >>>>>>>> >>>>>>>> Re: what the actual permissions are, FWIW I get what I see on both >>>>>>>> my macbook and my Fedora 27 machine, both when unzipping the actual >>>>>>>> 11.0.0.Final and when unzipping the result of a build of master, and both >>>>>>>> with and without the -Prelease -Pjboss-release args to maven that we >>>>>>>> include when doing actual releases. Unzipping the zip in build/target >>>>>>>> doesn't include the jars of course. >>>>>>>> >>>>>>>> So it sounds like we need input from others. >>>>>>>> >>>>>>>> Re: modules.xml, if you are seeing those as rw-r--r-- as well, >>>>>>>> then +1 to ignoring them in further discussion. >>>>>>>> >>>>>>>> Re: logging.properties, those serve a very similar conceptual role >>>>>>>> to the standalone|host|domain.xml files so I see no reason for them to have >>>>>>>> different perms. However, you and I are getting different results, where >>>>>>>> you report them as group writable and I don't. What do you see for the xml >>>>>>>> config files? >>>>>>>> >>>>>>>> Re: RPM changing to match WildFly, that's an EAP discussion, so >>>>>>>> that can be taken up elsewhere once we have WildFly the way we want it. >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran(a)redhat.com >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi Brian and all, >>>>>>>>> >>>>>>>>> err, my own observation differs from yours. I've rebuild Wildfly >>>>>>>>> from the last content of the master branch and get the same privileges on >>>>>>>>> the jboss-modules.jar (so -rw-rw-r-- and not as you are seeing rwxr--r--). >>>>>>>>> Same with the domain folder, which turns out on my local system associated >>>>>>>>> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a >>>>>>>>> transcript of what I did - maybe you can spot why our results differs so >>>>>>>>> much. >>>>>>>>> >>>>>>>>> $ git show >>>>>>>>> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f >>>>>>>>> Merge: 051f080 c7d9075 >>>>>>>>> Author: Kabir Khan <kkhan(a)redhat.com&gt; >>>>>>>>> Date: Tue Nov 28 17:46:40 2017 +0000 >>>>>>>>> >>>>>>>>> Merge pull request #10669 from praxeo/WFLY-9284 >>>>>>>>> >>>>>>>>> WFLY-9284 Correct MVN env variable to mvnw.cmd >>>>>>>>> >>>>>>>>> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d >>>>>>>>> wildfly-12.zip >>>>>>>>> ... >>>>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0. >>>>>>>>> Alpha1-SNAPSHOT/jboss-modules.jar >>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov. 11:41 >>>>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar >>>>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/ -d >>>>>>>>> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov. 11:41 >>>>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/ >>>>>>>>> >>>>>>>>> Checking all the jars in the distribution, they all appears to >>>>>>>>> have the mask '-rw-rw-r--': >>>>>>>>> >>>>>>>>> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done >>>>>>>>> | sed -e '/-rw-rw-r--/d' >>>>>>>>> $ >>>>>>>>> >>>>>>>>> Regarding properties files, here is the exhaustive list of >>>>>>>>> properties that RPM packaging has modified the privileges of: >>>>>>>>> >>>>>>>>> appclient/configuration/logging.properties rw------- >>>>>>>>> domain/configuration/application-roles.properties rw------- >>>>>>>>> domain/configuration/default-server-logging.properties rw------- >>>>>>>>> domain/configuration/logging.properties rw------- >>>>>>>>> domain/configuration/mgmt-groups.properties rw------- >>>>>>>>> standalone/configuration/application-roles.properties rw------- >>>>>>>>> standalone/configuration/logging.properties rw------- >>>>>>>>> standalone/configuration/mgmt-groups.properties rw------- >>>>>>>>> >>>>>>>>> If I compare that with the content of the extract zip (same fresh >>>>>>>>> built as above), I can see that 4 files are not having the same mask >>>>>>>>> (rw------): >>>>>>>>> >>>>>>>>> $ for file in $(cut -f1 -d\ ../../../list-props-files.txt ); do >>>>>>>>> ls -l $file ; done >>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov. 11:41 >>>>>>>>> appclient/configuration/logging.properties >>>>>>>>> -rw-------. 1 rpelisse rpelisse 710 30 nov. 11:41 >>>>>>>>> domain/configuration/application-roles.properties >>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov. 11:41 >>>>>>>>> domain/configuration/default-server-logging.properties >>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov. 11:41 >>>>>>>>> domain/configuration/logging.properties >>>>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov. 11:41 >>>>>>>>> domain/configuration/mgmt-groups.properties >>>>>>>>> -rw-------. 1 rpelisse rpelisse 711 30 nov. 11:41 >>>>>>>>> standalone/configuration/application-roles.properties >>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov. 11:41 >>>>>>>>> standalone/configuration/logging.properties >>>>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov. 11:41 >>>>>>>>> standalone/configuration/mgmt-groups.properties >>>>>>>>> >>>>>>>>> Now, as you said, those files privileges are indeed fine-grained, >>>>>>>>> so maybe we can push back to people making the RPM for them to NOT change >>>>>>>>> the following files privileges: >>>>>>>>> >>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov. 11:41 >>>>>>>>> appclient/configuration/logging.properties >>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov. 11:41 >>>>>>>>> domain/configuration/default-server-logging.properties >>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov. 11:41 >>>>>>>>> domain/configuration/logging.properties >>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov. 11:41 >>>>>>>>> standalone/configuration/logging.properties >>>>>>>>> >>>>>>>>> However, I don't see the value of letting those files accessible >>>>>>>>> either group member or any user on the system, but maybe we can make the >>>>>>>>> argument they should. But the write privileges for group member sounds >>>>>>>>> wrong to me. >>>>>>>>> >>>>>>>>> Also, I'm puzzled Brian and I are seeing different things - am I >>>>>>>>> looking at the correct zipfile here ? >>>>>>>>> >>>>>>>>> Note: You also mention the module.xml - as far as I can see from >>>>>>>>> the diff provided with issue JBEAP-12374, I don't see any issue with >>>>>>>>> privileges regarding those files, so we can remove them of the discussion. >>>>>>>>> The only changes we need to discuss is removing the 'write' privileges' for >>>>>>>>> the group on jars, reducing the scope of permissions on (some) folders, and >>>>>>>>> privileges on (some) properties files. So, module.xml are out of the scope. >>>>>>>>> >>>>>>>>> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry < >>>>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> Seems I forgot to "Reply to All" yesterday. The following was >>>>>>>>>> meant to be sent to wildfly-dev. >>>>>>>>>> >>>>>>>>>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry < >>>>>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>>>>> >>>>>>>>>>> Before getting into the specifics, first a general note re: >>>>>>>>>>> perms. >>>>>>>>>>> >>>>>>>>>>> Our general permission set for is rwxr-xr-x for directories and >>>>>>>>>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up. >>>>>>>>>>> ;). Otherwise I think any deviation from that we should justify. Not that >>>>>>>>>>> deviations are wrong, just that they need to have a reason. >>>>>>>>>>> >>>>>>>>>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse < >>>>>>>>>>> belaran(a)redhat.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> Well, the diff is between the RPM and the zipfile is pretty >>>>>>>>>>>> long, but it boils down to the 3 set of differences I've pointed out on >>>>>>>>>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574> >>>>>>>>>>>> >>>>>>>>>>>> - *.properties and .jar* files are associated with the >>>>>>>>>>>> mask rw-rw-r-- giving access to it to any other users and allowing group >>>>>>>>>>>> member to modify the file - the RPM distribution fixes that by removing the >>>>>>>>>>>> write privileges for the group (rw-r--r--). I personnaly don't see the >>>>>>>>>>>> value of letting the group members modify those files, I just can see how >>>>>>>>>>>> this could be exploited, so I would say it falls into "clearly wrong and >>>>>>>>>>>> not our intent". A case might be made for the .properties files, but for >>>>>>>>>>>> jars file I really don't see a valid use case (unless of course, any of you >>>>>>>>>>>> know one) ; >>>>>>>>>>>> >>>>>>>>>>>> There are a few different things here, so let's deal with them >>>>>>>>>>> separately. >>>>>>>>>>> >>>>>>>>>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them >>>>>>>>>>> as rwxr--r--. Which seems correct to me. In case I'm seeing something >>>>>>>>>>> wrong, I don't see why they should vary from the general standard. And the >>>>>>>>>>> module.xml file should be consistent, since there's not much point in >>>>>>>>>>> locking people from touching jars but letting them change what jars get >>>>>>>>>>> loaded. >>>>>>>>>>> >>>>>>>>>>> For properties files, let's consider them on a more >>>>>>>>>>> fine-grained basis. For example, the properties files used by the security >>>>>>>>>>> realms have different kinds of data than logging.properties does. >>>>>>>>>>> >>>>>>>>>>> The perms on the security realm property files are rw-------, >>>>>>>>>>> not rw-rw-r--. >>>>>>>>>>> >>>>>>>>>>> The logging.properties files are rw-r--r-- which is consistent >>>>>>>>>>> with the domain|host|standalone.xml files and with the general standard. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - >>>>>>>>>>>> - *some directories* like 'domain/tmp/auth' have too >>>>>>>>>>>> restrictive mask like rwx------ and RPMS to turned them into rwxrwxr-x >>>>>>>>>>>> (that I don't really agree with) and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - *other directories*, likes 'domain' have again a too >>>>>>>>>>>> permissive mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make >>>>>>>>>>>> senses. >>>>>>>>>>>> >>>>>>>>>>>> In the unzip I see these directories as rwxr-xr-x, which I >>>>>>>>>>> think is fine. >>>>>>>>>>> >>>>>>>>>>> Are you concerned with any other directories besides >>>>>>>>>>> $JBOSS_HOME/domain and $JBOSS_HOME/standalone? >>>>>>>>>>> >>>>>>>>>>>> So we need to find an agreement on those three items, and then >>>>>>>>>>>> see how we proceed to implement the fix (if needed). >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry < >>>>>>>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I think we need to start with the assumption that the >>>>>>>>>>>>> permissions we have in the zip are the way they are for a reason and >>>>>>>>>>>>> evaluate possible changes based on discussion here of each type of change. >>>>>>>>>>>>> Maybe the RPM settings are better, maybe they are not. Or maybe they are >>>>>>>>>>>>> better but the improvement is not worth the disruption a change may cause >>>>>>>>>>>>> to our end users, who may rely on the current zip settings. Or maybe what >>>>>>>>>>>>> we have in the zip is clearly wrong and doesn't follow our own intent. I >>>>>>>>>>>>> expect we'll probably see a little of each category, although hopefully >>>>>>>>>>>>> some changes for WF 11 removed the "clearly wrong and doesn't follow our >>>>>>>>>>>>> intent" cases. :) >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse < >>>>>>>>>>>>> belaran(a)redhat.com&gt; wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> As reported on JBEAP-12374[1], there is some discrepancies >>>>>>>>>>>>>> between the ZIP file we provided for Widlfy/EAP and the RPM generate. Most >>>>>>>>>>>>>> of those discrepancies - or the most relevant ones, are some fine tuning >>>>>>>>>>>>>> performed on the (POSIX) privileges (things such as removing the write >>>>>>>>>>>>>> privilege for member of the same group as the owner of the file). >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've looked into this and because those files are produced >>>>>>>>>>>>>> by our own Maven plugin (as part of wildfly-build-tools), we can not simply >>>>>>>>>>>>>> modify the assembly.xml. Which actually is probably for the best, as it >>>>>>>>>>>>>> would made the assembly file quite cumbersome. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Anyhow, I've worked on a proposal[2] for the >>>>>>>>>>>>>> wildfly-build-tools, but when I reported the problem on WFLY-9574[3], Brian >>>>>>>>>>>>>> suggested I started a discussion here. So does anyone have a (strong) >>>>>>>>>>>>>> opinion about this issue and/or how to resolve it ? :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> (For the record, I do think it is best to fix the privileges >>>>>>>>>>>>>> to follow what the RPM does for us for now, but if you feel this issue >>>>>>>>>>>>>> should not be addressed, and dev- the issue, I'm certainly not opposed to >>>>>>>>>>>>>> it either). >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374 >>>>>>>>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40 >>>>>>>>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574 >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> wildfly-dev mailing list >>>>>>>>>>>>>> wildfly-dev(a)lists.jboss.org >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Brian Stansberry >>>>>>>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>>>>>>> Red Hat >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Brian Stansberry >>>>>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>>>>> Red Hat >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Brian Stansberry >>>>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>>>> Red Hat >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Brian Stansberry >>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>> Red Hat >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Brian Stansberry >>>>>>> Manager, Senior Principal Software Engineer >>>>>>> Red Hat >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Manager, Senior Principal Software Engineer >>>>> Red Hat >>>>> >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >>> >>> -- >>> James R. Perkins >>> JBoss by Red Hat >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing listwildfly-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> >> >> >> -- >> James R. Perkins >> JBoss by Red Hat >> > > > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev