Bug 1434944

Alex Schultz confirmed that in TripleO we nuke that file because puppet handles the placement apache config.

https://github.com/openstack/puppet-nova/blob/master/manifests/wsgi/apache_placement.pp#L114-L122

We need to fix this issue in both RDO and RHOSP for anyone who deploys directly from packages (or basically any mechanism other than TripleO).

This is where the directory directive comes from in TripleO land:

https://github.com/openstack/puppet-openstacklib/blob/master/manifests/wsgi/apache.pp#L46-L48

I had a poke at the nova-placement-api_15.0.1-0ubuntu1~cloud0_all.deb package from Ubuntu's ocata-staging for the cloud archive and found that they do include the <Dirctory> directive:

"""
Listen 8778

<VirtualHost *:8778>
    WSGIScriptAlias / /usr/bin/nova-placement-api
    WSGIDaemonProcess nova-placement processes=5 threads=1 user=nova group=nova display-name=%{GROUP}
    WSGIProcessGroup nova-placement
    WSGIApplicationGroup %{GLOBAL}
    WSGIPassAuthorization On
    LimitRequestBody 114688

    <IfVersion >= 2.4>
      ErrorLogFormat "%{cu}t %M"
    </IfVersion>

    ErrorLog /var/log/apache2/nova_placement_error.log
    CustomLog /var/log/apache2/nova_placement_access.log combined

    <Directory /usr/bin>
        <IfVersion >= 2.4>
            Require all granted
        </IfVersion>
        <IfVersion < 2.4>
            Order allow,deny
            Allow from all
        </IfVersion>
    </Directory>
</VirtualHost>
"""

On IRC Alex pointed out that for TripleO driven deployments as well as Heat/Puppet controlling the config (which is why we see no issue there) his recollection is that they specifically didn't follow the directory approach because they hit issues. 

He suggested Emilien would probably remember the history better and that they  settled on just a vhost/port configuration since it's all hidden anyway.

I pushed a fix on RDO:

  https://review.rdoproject.org/r/#/c/5954/

Hi Lucy,

Have I set this up correctly to get a release note as "known issue" for GA?

Thanks,

Steve

I'll echo my comments from https://review.rdoproject.org/r/#/c/5954/ here for posterity...

We need to understand what is the problem, not address the symptom by exposing /usr/bin through a web server. That's anything but a good idea.

What is required from /usr/bin exactly ? The trace isn't very explicit.
Is it a wsgi script or something like that ?

Puppet modules approaches this by copying the wsgi scripts to /var/www/cgi-bin and then specifying the necessary configuration to expose that directory.
References:
    https://github.com/openstack/puppet-nova/blob/master/manifests/wsgi/apache_placement.pp#L129
    https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L53-L55
    https://github.com/openstack/puppet-openstacklib/blob/master/manifests/wsgi/apache.pp

Petr mentions a thread from openstack-dev [1] that provides the Directory directive "workaround" and cites the same concern:

    > That can be fixed by doing (somewhere in your apache config):
        <Directory /usr/bin>
            Require all granted
        </Directory>
    but rather than doing that you may wish to move nova-placement-api
    to a less global directory and grant access to that directory.
    Providing wide access to /usr/bin is not a great idea.

The fact that the official documentation provides a workaround with serious security implications rather than showing the right way (placing wsgi/api scripts in another directory such as /var/www/cgi-bin) is quite concerning and should be addressed.

I've pinged an Ubuntu package maintainer (James Page) about the issue as Ubuntu includes the virtualhost /usr/bin directive right in the package.

[1]: http://lists.openstack.org/pipermail/openstack-dev/2017-March/113550.html

Thanks for the input, David. I'll address the documentation issue once we have a working solution.

The doc text will also need to be updated accordingly.

Clearing the needinfo on me. Once the doc text is updated and reviewed by docs again (as per Petr's note in comment 7), this text can be pulled in to the Release Notes.

Steve, in light of comment 6, does the doc text need to be updated with an alternative workaround? We'll need to know ASAP if we want this to appear in the Release Notes.

(In reply to Lucy Bopf from comment #10)
> Steve, in light of comment 6, does the doc text need to be updated with an
> alternative workaround? We'll need to know ASAP if we want this to appear in
> the Release Notes.

I've yet to see an alternative proposed in the packaging, so right now I believe the release note as stated remains the best solution we have and better than no solution (which is current state).

OSP11 is now retired, see details at https://access.redhat.com/errata/product/191/ver=11/rhel---7/x86_64/RHBA-2018:1828

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days