Prevent Apache from serving uploads directly

As pointed out in https://gitlab.com/gitlab-org/gitlab-recipes/issues/43#note_4337464, access control checks could be in place when requesting some uploaded files.

Any request concerning uploads now get explicitly forwarded to workhorse/rails, leaving other static files unaffected. The latter is needed for the maintenance page to work properly, as mentioned in #43 (closed).

Other static files should not be subject to access restrictions, as far as I checked my own installation.

Status changed to merged

@Zenti thanks once again for your time

Finally got a chance to upgrade my instance.

Apache 2.2, when workhorse is down I get service unavailable instead of deploy page. Can't access https://my.instance.com/deploy.html either.

My config snippet:

  # needed for downloading attachments
  DocumentRoot /home/gitlab/gitlab/public/

  #Don't escape encoded characters in api requests
  RewriteCond %{REQUEST_URI} ^/api/v3/.* [OR]
  RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]

  #Forward all requests to gitlab-workhorse except existing files like error documents
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
  RewriteCond %{REQUEST_URI} ^/uploads/.*
  RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA]

  RequestHeader set X_FORWARDED_PROTO 'https'
  RequestHeader set X-Forwarded-Ssl on

  #Set up apache error documents, if back end goes down (i.e. 503 error) then a maintenance/deploy page is thrown up.
  ErrorDocument 404 /404.html
  ErrorDocument 422 /422.html
  ErrorDocument 500 /500.html
  ErrorDocument 503 /deploy.html

I was able to reach some sort of success with bogus rule with [S=1] flag when request file is 'deploy.html' but looked so hackish so I decided to drop it.

When I start all gitlab services back everything works fine and I can even request '/deploy.html'.

I was thinking that apache somehow does not set %{REQUEST_FILENAME} to 'deploy.html' when it get 503 since original request was for something like '/dashboard/activity'. But in this case I am not sure how my hacks with [S=1] flag worked then.

@Zenti was it working on your setup? Which apache version do you have?

@bak1an My current config file looks like this:

# needed for downloading attachments
DocumentRoot /home/git/gitlab/public

RewriteEngine on

RewriteCond %{REQUEST_URI} ^/api/v3/.*
RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]

#Forward all requests to gitlab-workhorse except existing files like error documents
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_URI} ^/uploads/.*
RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA]

RequestHeader set X_FORWARDED_PROTO 'https'
RequestHeader set X-Forwarded-Ssl on

#Set up apache error documents, if back end goes down (i.e. 503 error) then a maintenance/deploy page is thrown up.
ErrorDocument 404 /404.html
ErrorDocument 422 /422.html
ErrorDocument 500 /500.html
ErrorDocument 503 /deploy.html

I'm using Apache 2.4, but as far as rewrite rules go, Apache versions shouldn't matter. It does work with on my setup.

However, I see you set your DocumentRoot to /home/gitlab/gitlab/public/. Is your GitLab instance running under the username 'gitlab'? If not, can you try to set DocumentRoot to /home/git/gitlab/public/ and report back on the result? DocumentRoot tells Apache where to look for static files if the proxy (in our case gitlab-workhorse) is not available.

@Zenti I indeed use 'gitlab' user to deploy my instance. Apache was successfully serving static files from the very same document root for several years before we got workhorse.

$ ls -lh /home/gitlab/gitlab/public/deploy.html 
-rw-r--r-- 1 gitlab gitlab 404 Jul 30  2015 /home/gitlab/gitlab/public/deploy.html

@Zenti Found it!

#Don't escape encoded characters in api requests
  RewriteCond %{REQUEST_URI} ^/api/v3/.* [OR]
  RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]

  #Forward all requests to gitlab-workhorse except existing files like error documents
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
  RewriteCond %{REQUEST_URI} ^/uploads/.*
  RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA]

Note that [OR] flag near api rewrite cond. I copypasted it from there - https://gitlab.com/gitlab-org/gitlab-recipes/blob/59956b822368f1c173f83ee983a6102463ed2f48/web-server/apache/gitlab-ssl-apache22.conf

Somehow my apache was feeling bad about it (can't explain why) and without workhorse running I was not able even to fetch stuff like robots.txt.

Without [OR] near api condition it works fine!

@bak1an That is good to hear!

I myself did notice that flag, which isn't supposed to be there. I already submitted the removal of that flag for the api rewrite as a MR, see !54 (merged).

mentioned in merge request !54 (merged)

@Zenti Thanks!

!54 (merged) merged! Thank you guys for debugging and fixing this :)