[wildfly-dev] WFLY-9574 - Distribution files does not have POSIX permissions perfectly set
Carlo de Wolf
cdewolf at redhat.com
Tue Dec 12 03:20:13 EST 2017
If any target platform needs more restrictive permissions, those need to
apply to all deliverables (whether it is ZIP or RPMs).
Carlo
On 11-12-17 23:28, James Perkins wrote:
> I personally don't have any strong opinions on what the permissions
> should be. However as I said before it should definitely not be the
> provisioning plugin that sets these permissions. If they need to be
> different we need to change them in the feature pack.
>
> On Mon, Dec 11, 2017 at 4:47 AM, Romain Pelisse <belaran at redhat.com
> <mailto: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 <mailto:brian.stansberry at redhat.com>>
> wrote:
>
> On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse
> <belaran at redhat.com <mailto: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
> <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
> <mailto: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
> <mailto: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 <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <https://issues.jboss.org/browse/JBEAP-12374>
> [2]
> https://github.com/wildfly/wildfly-build-tools/pull/40
> <https://github.com/wildfly/wildfly-build-tools/pull/40>
> [3]
> https://issues.jboss.org/browse/WFLY-9574
> <https://issues.jboss.org/browse/WFLY-9574>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> <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 <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
>
> --
> James R. Perkins
> JBoss by 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/dcaaeb2d/attachment-0001.html
More information about the wildfly-dev
mailing list