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

Ken Wills kwills at redhat.com
Tue Dec 12 14:44:47 EST 2017 

At a quick look, the permissions set in the WF11 zip look mostly
appropriate to me. For example, I don't understand why the RPM version
needs to set ugo+r on standalone/configuration/mgmt-groups.properties and
stuff like that.

So I'd vote, they should probably be the same, but i'd rather see a
justification for why the RPM ones were changed, then see those changes go
into WF so they're the same.

Ken

On Mon, Dec 11, 2017 at 7:43 AM Romain Pelisse <belaran at 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 at redhat.com> wrote:
>
>> On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse <belaran at 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 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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
>>>>>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>>>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>>> wildfly-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171212/ba09a80d/attachment-0001.html

More information about the wildfly-dev mailing list