Re: [wildfly-dev] WFLY-9574 - Distribution files does not have POSIX permissions perfectly set

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&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 > -- 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