misterunknown: Apache: Limiteren von Methoden auf Gruppenbasis

Moin,

ich hab ein sehr komisches Problem mit dem Apache. Ich möchte einen Apache-Proxy anlegen, der eine rudimentäre Rechteverwaltung für Elasticsearch bietet. Um selbiges zu realisieren, muss man sowohl die URL prüfen, als auch die Requestmethode. Elasticsearch nutzt leider nicht nur GET und POST, sondern auch PUT, HEAD, und DELETE. Um diese Methoden einzuschränken will ich die Direktive "Limit" verwenden. Mein experimenteller Aufbau:

<VirtualHost *:80>  
    ServerName es.example.com  
    ProxyRequests On  
    ProxyPreserveHost On  
    ProxyPass / http://localhost:9200/  
    ProxyPassReverese / http://localhost:9200/  
  
    <Location ~ "^.*">                  # <- Jeglicher Zugriff wird...  
        AuthType Basic  
        AuthName ...  
        AuthUserFile ...  
        AuthGroupFile ...  
        Require group myadmins          # <- nur der Gruppe "myadmins" gewährt.  
        <Limit PUT DELETE>              # <- Die Methoden PUT und DELETE werden...  
            #Order deny,allow  
            #Deny from all  
            Require group myadmins      # <- ebenfalls nur "myadmins" gewährt.  
        </Limit>  
    </Location>  
	  
    ## Freigeben von Indexen, die auf ein Regex-Muster passen  
  
    # Beispiel: prefix-  
    <Location ~ "^/prefix-.*">          # <- Indexe mit dem Präfix "prefix-" werden...  
        Require group myusers myadmins  # <- ... für die Gruppe "myusers" freigegeben  
    </Location>  
</VirtualHost>

Der URL-basierte Zugriffsschutz funktioniert problemlos; ein User ("myusers") kann also nur auf die Indexe, die auf den regulären Ausdruck matchen, zurgeifen, und auf nichts anderes.

In diesem Aufbau kann er aber trotzdem einen Index anlegen auf den er URL-basiert Zugriff hat; also mit dem Präfix "prefix-":

$ curl -XPUT 'http://es.example.com/prefix-neu/' -u normaluser  
{"acknowledged":true}

Eigentlich sollte er das durch die Einschränkung der Methoden nicht dürfen!

Erst hab ich gedacht, dass die Limit-Direktive gar nicht im Location-Kontext stehen darf oder nicht ausgewertet wird. Dem ist aber nicht so! Wenn ich nämlich in der obigen Konfiguration die "Require"-Direktive auskommentiere und dafür "Order deny,allow" und "Deny from all" einkommentiere, dann wirkt das wie erwartet: Niemand darf einen Index anlegen oder löschen.

Hat jemand eine Idee was da falsch läuft?

Grüße Marco

--
Ich spreche Spaghetticode - fließend.
  1. Hi,

    <Location ~ "^.*">                  # <- Jeglicher Zugriff wird...
            AuthType Basic
            AuthName ...
            AuthUserFile ...
            AuthGroupFile ...
            Require group myadmins          # <- nur der Gruppe "myadmins" gewährt.
            <Limit PUT DELETE>              # <- Die Methoden PUT und DELETE werden...
                #Order deny,allow
                #Deny from all
                Require group myadmins      # <- ebenfalls nur "myadmins" gewährt.
            </Limit>
        </Location>

      
    Wozu soll hier <LIMIT> gut sein? Du hast doch bereits generellen Zugriff für die Gruppe unabhängig von der Request-Methode gewährt – welchen Sinn soll es da haben, das gleiche für PUT und DELETE noch mal zu machen?  
      
      
    
    > ~~~apache
     	  
    
    >     ## Freigeben von Indexen, die auf ein Regex-Muster passen  
    >   
    >     # Beispiel: prefix-  
    >     <Location ~ "^/prefix-.*">          # <- Indexe mit dem Präfix "prefix-" werden...  
    >         Require group myusers myadmins  # <- ... für die Gruppe "myusers" freigegeben  
    >     </Location>  
    > </VirtualHost>
    
    

    Der URL-basierte Zugriffsschutz funktioniert problemlos; ein User ("myusers") kann also nur auf die Indexe, die auf den regulären Ausdruck matchen, zurgeifen, und auf nichts anderes.

    In diesem Aufbau kann er aber trotzdem einen Index anlegen auf den er URL-basiert Zugriff hat; also mit dem Präfix "prefix-":

    $ curl -XPUT 'http://es.example.com/prefix-neu/' -u normaluser

    {"acknowledged":true}

    
    > Eigentlich sollte er das durch die Einschränkung der Methoden nicht dürfen!  
      
    Die Methode ist für diese Location nicht eingeschränkt.  
      
    
    > Hat jemand eine Idee was da falsch läuft?  
      
    <http://httpd.apache.org/docs/2.2/en/mod/core.html#location>: “<Location> sections are processed in the order they appear in the configuration file”  
      
    Ich würde vermuten, dass es daran liegt – deine zweite <Location> schränkt den Zugriff per Methode PUT nicht weiter ein, als einen Nutzer aus der Gruppe myusers zu verlangen – das ist gegeben, also darf der Nutzer PUTten.  
      
    MfG ChrisB  
      
    
    -- 
    Autocomplete has spoiled me to a point where it happens every so often that I encounter a CAPTCHA, and I just type in the first character … and then wait for the rest of the code to be automatically suggested :/
    
    1. Moin,

      Wozu soll hier <LIMIT> gut sein? Du hast doch bereits generellen Zugriff für die Gruppe unabhängig von der Request-Methode gewährt – welchen Sinn soll es da haben, das gleiche für PUT und DELETE noch mal zu machen?

      Das hat den Sinn, dass ich – theoretisch – diese Einschränkung nicht nochmal in allen Locations machen muss, die ich danach festlege.

      Die Methode ist für diese Location nicht eingeschränkt.
      Ich würde vermuten, dass es daran liegt – deine zweite <Location> schränkt den Zugriff per Methode PUT nicht weiter ein, als einen Nutzer aus der Gruppe myusers zu verlangen – das ist gegeben, also darf der Nutzer PUTten.

      Ich habe testweise die Limits nochmal in die andere Location mit reingenommen: kein Erfolg. Grundsätzlich ist es so, dass die Location-Direktiven für eine bestimmte URL zusammengefasst werden. Das heißt, dass für eine URL alle Einstellungen wirksam werden, die in Location-Direktiven stehen, die darauf matchen. Da ich in der ersten Location _alle_ URLs einbeziehe, sollte der Aufbau so korrekt sein. Das merkt man auch daran, dass wenn ich den Zugriff per "Order" und "Deny" steuere, selbiges global wirkt.

      Grüße Marco

      --
      Ich spreche Spaghetticode - fließend.