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

• .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@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@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@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