[wildfly-dev] WFLY-9574 - Distribution files does not have POSIX permissions perfectly set
Romain Pelisse
belaran at redhat.com
Mon Dec 11 07:47:29 EST 2017
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171211/b4b267ff/attachment-0001.html
More information about the wildfly-dev
mailing list