☰

Quais são as permissões a serem definidas na raiz do SVN?

tag-icon • tag-icon apache-2.2 security permissions svn
Quais são as permissões a serem definidas na raiz do SVN?

Estou tentando fornecer acesso remoto ao servidor SVN através do Apache. A situação pode ser ilustrada assim:

/root
    /public-project
        /trunk
        /branches
    /restricted-project
        /trunk
        /branches

Existe apenas um repositório, que contém os dois projetos.

Os projetos públicos podem ser visualizados por qualquer pessoa (apenas visualizados, nunca modificados). Os restritos podem ser lidos/modificados apenas pelos usuários que pertencem a grupos específicos. A configuração é a seguinte:

<Location "/root">
  DAV svn
  SVNPath [...]
  SVNIndexXSLT [...]
  [...]
  <LimitExcept PROPFIND OPTIONS REPORT>
    require ldap-group CN=SVN Administrators,OU=Subversion,DC=example,DC=com
  </LimitExcept>
</location>

<Location "/root/public-project">
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    require ldap-group CN=Project1 Contributors,OU=Subversion,DC=example,DC=com
  </LimitExcept>
</location>

<Location "/root/restricted-project">
  require ldap-group CN=Project2 Contributors,OU=Subversion,DC=example,DC=com
</location>

  1. É seguro o suficiente ou existe a possibilidade de um convidado acessar informações confidenciais do projeto restrito?

  2. Ao atualizar a fonte do projeto público através do SVN, recebo o seguinte erro:

    Não autorizado a abrir a raiz da operação de edição

    Apache error.log mostra os seguintes elementos:

    Ocorreu uma falha ao dirigir o editor de relatório de atualização [500, #220000]
    Não autorizado a abrir a raiz da operação de edição [500, #220000]

    Quanto ao access.log, mostra que o cliente SVN fez vários PROPFIND(resposta: HTTP 207) e OPTIONS(resposta: HTTP 200) e, finalmente:

    "RELATÓRIO /root/!svn/vcc/default HTTP/1.1" 500 241

    O que devo fazer para resolver esse problema, ou seja, permitir o acesso público somente leitura para o projeto público, mantendo o restrito oculto de usuários não autorizados?

Nota: conceder o privilégio GET /rootpermite que um convidado carregue a fonte do projeto público, mas também torna o comportamento público o padrão. Eu preferiria restringir o acesso e concedê-lo apenas em nós que contenham projetos públicos.

Responder1

Eu construí um ambiente novo do zero e brinquei com sua configuração, mas parece que oapenasA maneira é definir tudo como público por padrão e, em seguida, restringir explicitamente projetos específicos.

Isto é completamente tolo em termos de segurança, especialmente no contexto onde muitos projetos são criados, às vezes não totalmente automatizados, tornando fácil cometer um erro ao esquecer de colocar uma restrição. Dito isto, também obriga a avançar ainda mais a automação, o que só pode ser benéfico.

Se alguém quiser brincar com as configurações, posso fornecer a configuração atual usada.

informação relacionada