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