configuração de acesso SVN

1

Eu herdei um servidor Fedora 17 que é usado para hospedar repositórios do Subversion.

Eu pensei que ele foi configurado com acesso muito limitado, mas alguns testes hoje revelam que não há controle de acesso, RW universal, oops.

Aqui estão algumas informações do sistema:

uname -a

Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

httpd -v

Server version: Apache/2.2.23 (Unix) Server built: Jan 29 2013 12:37:17

Aqui está um trecho de parte dos arquivos de configuração do HTTPD

<Location /svn/proj>
    DAV                             svn
    SVNParentPath                   /data/subversion/repos/proj
    SVNAutoversioning               On
    SSLRequireSSL
    SVNIndexXSLT                    "/repostyle-proj/view/repos.xsl"
    AuthType                        Basic
    AuthName                        "Project Authorization"
    PerlAuthenHandler               Apache::AuthPOP3
    PerlSetVar                      MailHost 127.0.0.1
    AuthBasicAuthoritative          On
    AuthzSVNAccessFile              /data/subversion/conf/perms_proj
    Require valid-user
    SVNAdvertiseV2Protocol Off

</Location>

Aqui está um trecho do arquivo de permissões do SVN

[groups]
admins=admin-user
dummy-proj=<list of users>

[/]
@admins=rw

[dummy-proj:/]
@dummy-proj=rw

Ao executar

svn co link

Eu obtenho acesso total ao repositório, mesmo que esteja autenticando como um usuário que não seja o 'admin-user' ou um usuário na 'lista de usuários'.

O que eu configurei incorretamente?

Mais informações - adicionada em 18/04/17 11:00

Parece que os arquivos especificados nas linhas "AuthzSVNAccessFile" não estão sendo lidos ou estão sendo completamente ignorados.

Para testar, renomeiei o arquivo e acessei o repositório sem problemas. Eu também deletei essa linha do arquivo de configuração e ainda consegui acessar o repositório.

Como posso obter alguma depuração do AuthzSVN? Eu quero ver o nome de usuário que ele está validando, e confirmo que o arquivo está sendo lido.

Obrigado por qualquer ajuda

    
por shifflettd 14.04.2017 / 21:37

1 resposta

0

Eu aprendi com aqui que as permissões no SVN são diferentes entre o protocolo svn:// e o http(s):// . Linda .

Suas permissões de HTTP do SVN provavelmente vêm de seu servidor da web , que pode ser Apache, Lighttpd, nginx, etc. Veja aqui: link

Basicamente, você precisa:

  • Descubra qual servidor da web você está usando para hospedar o endpoint http (s) para o SVN
  • Determine qual mecanismo de autenticação está sendo usado por esse servidor da Web, se houver
  • Bloqueie-o se não houver autenticação, implementando, por exemplo Autenticação do Windows / LDAP, auth do PAM, auth básico ou auth do Digest e, em seguida, definir uma permissão específica do servidor da web por usuário / grupo
  • Apenas para garantir a máxima confusão, verifique se você (provavelmente) não tem esses direitos de acesso de R / W completos se você for svn co svn:// (usando o protocolo nativo SVN em vez de HTTP).

BTW, isso não está relacionado à sua pergunta, mas o Fedora 17 não é suportado por atualizações de segurança ou bugfix em cerca de 4 anos, então você deve realmente atualizar para um sistema operacional suportado. O RHEL / CentOS 7.x é baseado no Fedora 19 (com muitos patches e backports mais recentes para melhor suporte a hardware e estabilidade), então por causa da semelhança entre o Fedora 17 e o CentOS / RHEL 7.x, ele seria relativamente baixo. esforço para salvar arquivos de configuração e dados do servidor e reinstalar o sistema operacional como o CentOS / RHEL 7.x. E então você começaria a receber um fluxo constante de atualizações de segurança novamente por alguns anos ainda (por volta de 2023).

Se você encontrar problemas que se assemelham a bugs ou funcionalidades quebradas no Fedora 17, quase ninguém estará motivado para ajudá-lo em qualquer capacidade, então esse é outro motivo motivador para atualizar. Se você encontrar algo quebrado no CentOS 7.x, e pode escrever um bom relatório de bug, ele pode ser consertado pela Red Hat ou por um contribuidor da comunidade, e você pode baixar o patch como uma atualização estável. Há uma grande diferença entre a execução de um sistema operacional compatível e um não suportado, especialmente se você tiver uma empresa que dependa da funcionalidade correta desse servidor. Você está brincando com fogo se você tem pessoas fazendo trabalhos importantes com base neste servidor.

    
por 14.04.2017 / 21:52