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