[svnbook-pt-br commit] r133 - trunk/book

codesite-noreply at google.com codesite-noreply at google.com
Sat Aug 2 21:06:54 CDT 2008


Author: mfandrade
Date: Sat Aug  2 19:06:30 2008
New Revision: 133

Modified:
   trunk/book/ch06-server-configuration.xml

Log:
Tradução do capítulo 6 - "Configuração de servidor", seção "Autorização
Baseada em Caminhos".


Modified: trunk/book/ch06-server-configuration.xml
==============================================================================
--- trunk/book/ch06-server-configuration.xml	(original)
+++ trunk/book/ch06-server-configuration.xml	Sat Aug  2 19:06:30 2008
@@ -2430,115 +2430,120 @@
   <!-- ================================================================= -->
   <sect1 id="svn.serverconfig.pathbasedauthz">
 
-    <title>Path-Based Authorization</title>
+    <title>Autorização Baseada em Caminhos</title>
 
-    <para>Both Apache and <command>svnserve</command> are capable of
-      granting (or denying) permissions to users.  Typically this is
-      done over the entire repository: a user can read the repository
-      (or not), and she can write to the repository (or not).  It's
-      also possible, however, to define finer-grained access rules.
-      One set of users may have permission to write to a certain
-      directory in the repository, but not others; another directory
-      might not even be readable by all but a few special
-      people.</para>
-
-    <para>Both servers use a common file format to describe these
-      path-based access rules.  In the case of Apache, one needs to
-      load the <command>mod_authz_svn</command> module and then add
-      the <literal>AuthzSVNAccessFile</literal> directive (within
-      the <filename>httpd.conf</filename> file) pointing to your own
-      rules-file.  (For a full explanation, see
-      <xref linkend="svn.serverconfig.httpd.authz.perdir"/>.)  If
-      you're using <command>svnserve</command>, then you need to make
-      the <literal>authz-db</literal> variable
-      (within <filename>svnserve.conf</filename>) point to your
-      rules-file.</para>
+    <para>Tanto o Apache como o <command>svnserve</command> são capazes
+      garantir (ou negar) permisssões aos usuários.  Tipicamente isto é
+      feito considerando todo o repositório: um usuário pode ler o
+      repositório (ou não), e pode escrever no repositório (ou não).  No
+      entanto, também é possível definir regras de acesso mais
+      pormenorizadas.  Um conjunto de usuários podem ter permissão para
+      escrever em um certo diretório do repositório, mas não em outros;
+      outro diretório pode não ser legível por todos, exceto alguns
+      usuários em particular.</para>
+
+    <para>Ambos os servidores usam um formato de arquivo comum para
+      descrever estas regras de acesso baseadas em caminhos.  No caso do
+      Apache, precisa-se carregar o módulo
+      <command>mod_authz_svn</command> e então adicionar-se a diretiva 
+      <literal>AuthzSVNAccessFile</literal> (dentro do arquivo 
+      <filename>httpd.conf</filename>) para apontar para seu arquivo de
+      regras.  (Para uma descrição completa, veja
+      <xref linkend="svn.serverconfig.httpd.authz.perdir"/>.)  Se você
+      está usando o <command>svnserve</command>, então você precisa fazer
+      a variável <literal>authz-db</literal> (dentro do 
+      <filename>svnserve.conf</filename>) apontar para seu arquivo de
+      regras.</para>
 
     <sidebar>
-      <title>Do you really need path-based access control?</title>
+      <title>Você realmente precisa de controle de acesso baseado em
+        caminhos?</title>
 
-      <para>A lot of administrators setting up Subversion for the
-        first time tend to jump into path-based access control without
-        giving it a lot of thought.  The administrator usually knows
-        which teams of people are working on which projects, so it's
-        easy to jump in and grant certain teams access to certain
-        directories and not others.  It seems like a natural thing,
-        and it appeases the administrator's desire to maintain tight
-        control of the repository.</para>
-
-      <para>Note, though, that there are often invisible (and
-        visible!) costs associated with this feature.  In the visible
-        category, the server needs to do a lot more work to ensure
-        that the user has the right to read or write each specific
-        path; in certain situations, there's very noticeable
-        performance loss.  In the invisible category, consider the
-        culture you're creating.  Most of the time, while certain
-        users <emphasis>shouldn't</emphasis> be committing changes to
-        certain parts of the repository, that social contract doesn't
-        need to be technologically enforced.  Teams can sometimes
-        spontaneously collaborate with each other; someone may want to
-        help someone else out by committing to an area she doesn't
-        normally work on.  By preventing this sort of thing at the
-        server level, you're setting up barriers to unexpected
-        collaboration.  You're also creating a bunch of rules that
-        need to be maintained as projects develop, new users are
-        added, and so on.  It's a bunch of extra work to
-        maintain.</para>
-
-        <para>Remember that this is a version control system!  Even if
-        somebody accidentally commits a change to something they
-        shouldn't, it's easy to undo the change.  And if a user
-        commits to the wrong place with deliberate malice, then it's a
-        social problem anyway, and that the problem needs to be dealt
-        with outside of Subversion.</para>
-
-      <para>So before you begin restricting users' access rights, ask
-        yourself if there's a real, honest need for this, or if it's
-        just something that <quote>sounds good</quote> to an
-        administrator.  Decide whether it's worth sacrificing some
-        server speed for, and remember that there's very little risk
-        involved; it's bad to become dependent on technology as a
-        crutch for social problems.<footnote><para>A common theme in
-        this book!</para></footnote>.</para>
-
-      <para>As an example to ponder, consider that the Subversion
-        project itself has always had a notion of who is allowed to
-        commit where, but it's always been enforced socially.  This is
-        a good model of community trust, especially for open-source
-        projects.  Of course, sometimes there <emphasis>are</emphasis>
-        truly legitimate needs for path-based access control; within
-        corporations, for example, certain types of data really can be
-        sensitive, and access needs to be genuinely restricted to
-        small groups of people.</para>
+      <para>Muitos administradores que configuram o Subversion pela
+        primeira vez tendem a usar controle de acesso baseado em caminhos
+        mesmo sem pensar muito sobre ele.  O administrador comumente sabe
+        quais equipes de pessoas estão trabalhando em quais projetos,
+        então é fácil considerar isso e permitir que certas equipes
+        acessem determinados diretórios e não outros.  Parece uma coisa
+        natural, e isso até tranquiliza os desejos dos administradores de
+        manter um controle rígido do repositório.</para>
+
+      <para>Perceba, porém, que sempre há custos invisíveis (e visíveis!)
+        associados a este recurso.  Quanto aos custos visíveis, tem-se
+        que o servidor precisa de muito mas esforço para garantir que
+        cada usuário tenha o acesso correto de leitura ou escrita em cada
+        caminho específico; em certas circunstâncias, há uma sensível
+        perda de desempenho.  Quanto aos custos invisíveis, considere a
+        cultura que você está criando.  Na maior parte do tempo, ainda
+        que certos usuários <emphasis>não devessem</emphasis> estar
+        registrando alterações em certas partes do repositório, este
+        contrato social não precisa ser reforçado tecnologicamente.
+        Algumas vezes as equipes podem colaborar umas com as outras
+        espontaneamente; alguém pode querer ajudar a algum outro fazendo
+        alterações em alguma parte na qual não trabalha normalmente.
+        Ao prevenir este tipo de coisa a nível de servidor, você está
+        criando inesperadas barreiras à colaboração.  Você também está
+        criando um monte de regras que deverão ser mantidas conforme os
+        projetos são desenvolvidos, novos usuários são adicionados, e por
+        aí vai.  É muito trabalho extra para manter.</para>
+
+      <para>Lembre-se de que isto é um sistema de controle de versão!
+        Mesmo que alguém acidentalmente faça alguma alteração em algo que
+        não deveria, é fácil desfazer a alteração.  E se um usuário
+        registrar uma modificação intencionalmente no lugar errado, isto
+        é um problema social de qualquer maneira, e este é um problema
+        que precisará ser tratado fora do Subversion.</para>
+
+      <para>Então antes de começar a restringir os direitos de acesso dos
+        usuários, pergunte a si mesmo se há uma razão real e legítima
+        para isto, ou se não é algo que apenas <quote>parece uma boa
+        idéia</quote> para um administrador.  Decida ainda se vale a pena
+        sacrificar um pouco da velocidade do servidor, e lembre-se que há
+        muito pouco risco envolvido; é ruim se tornar dependente da
+        tecnologia como uma muleta para problemas
+        sociais<footnote><para>Um tema recorrente neste
+        livro!</para></footnote>.</para>
+
+      <para>Como um exemplo a considerar, veja que o próprio projeto
+        Subverion sempre teve a noção de quem tem permissão para realizar
+        alterações em que lugares, mas isto já é o que acaba ocorrendo na 
+        prática.  Este é um bom modelo de confiança da comunidade,
+        especialmente para projetos
+        <foreignphrase>open-source</foreignphrase>.  De fato, algumas
+        vezes <emphasis>há</emphasis> razões verdadeiramente legítimas
+        para se ter controle de acesso baseado em caminhos; em empresas,
+        por exemplo, certos tipos de dados realmente podem ser sensíveis,
+        aos quais os acessos precisam ser verdadeiramente restritos a
+        pequenos grupos de pessoas.</para>
 
     </sidebar>
 
-    <para>Once your server knows where to find your rules-file, it's
-      time to define the rules.</para>
+    <para>Uma vez que o servidor saiba onde encontrar seu arquivo de
+      regras, é hora de definí-las.</para>
 
-    <para>The syntax of the file is the same familiar one used
-      by <command>svnserve.conf</command> and the runtime
-      configuration files.  Lines that start with a hash
-      (<literal>#</literal>) are ignored.  In its simplest form, each
-      section names a repository and path within it, and the
-      authenticated usernames are the option names within each
-      section.  The value of each option describes the user's level of
-      access to the repository path: either
-      <literal>r</literal> (read-only) or <literal>rw</literal>
-      (read-write).  If the user is not mentioned at all, no access is
-      allowed.</para>
-
-    <para>To be more specific: the value of the section-names are
-      either of the form <literal>[repos-name:path]</literal> or the
-      form <literal>[path]</literal>.  If you're using the
-      <literal>SVNParentPath</literal> directive, then it's important
-      to specify the repository names in your sections.  If you omit
-      them, then a section like
-      <literal>[/some/dir]</literal> will match the path
-      <filename>/some/dir</filename> in <emphasis>every</emphasis>
-      repository.  If you're using the <literal>SVNPath</literal>
-      directive, however, then it's fine to only define paths in your
-      sections—after all, there's only one repository.</para>
+    <para>A sintaxe do arquivo é aquela mesma sintaxe familiar usada no
+      <command>svnserve.conf</command> e nos arquivos de configuração em
+      tempo de execução.  Linhas que comecem com cerquilha
+      (<literal>#</literal>) são ignoradas.  Em sua forma mais simples,
+      cada seção nomeia um repositório e um caminho dentro dele, e os
+      nomes de usuários autenticados são os nomes das opções dentro de
+      cada seção.  O valor de cada opção descreve o nível de acesso dos
+      usuários naquele caminho do repositório: seja
+      <literal>r</literal> (somente leitura) ou <literal>rw</literal>
+      (leitura/escrita).  Se o usuário não for mencionado de forma
+      nenhuma, nenhum acesso será permitido.</para>
+
+    <para>Para ser mais específico: o valor dos nomes das seções ou são
+      da forma <literal>[repos-name:path]</literal> ou da forma
+      <literal>[path]</literal>.  Se você está usando a diretiva 
+      <literal>SVNParentPath</literal>, então é importante especificar os
+      nomes dos repositórios em suas seções.  Se você omití-los, então
+      uma seção como <literal>[/algum/dir]</literal> irá corresponder ao
+      caminho <filename>/algum/dir</literal> em <emphasis>cada</emphasis>
+      repositório.  Se você está usando a diretiva
+      <literal>SVNPath</literal>, porém, então não há problema em definir
+      apenas os caminhos em suas seções—afinal de contas, há apenas
+      um repositório.</para>
 
     <screen>
 [calc:/branches/calc/bug-142]
@@ -2546,35 +2551,36 @@
 sally = r
 </screen>
 
-    <para>In this first example, the user <literal>harry</literal> has
-      full read and write access on the
-      <filename>/branches/calc/bug-142</filename> directory in the
-      <literal>calc</literal> repository, but the user
-      <literal>sally</literal> has read-only access.  Any other users
-      are blocked from accessing this directory.</para>
-
-    <para>Of course, permissions are inherited from parent to child
-      directory.  That means that we can specify a subdirectory with a
-      different access policy for Sally:</para>
+    <para>Neste primeiro, o usuário <literal>harry</literal> tem completo
+      acesso de leitura e escrita ao diretório 
+      <filename>/branches/calc/bug-142</filename> no repositório 
+      <literal>calc</literal>, mas o usuário
+      <literal>sally</literal> tem acesso somente leitura.  Quaisquer
+      outros usuários têm seu acesso a este repositório bloqueado.</para>
+
+    <para>É claro que as permissões são herdadas de um diretório para
+      um filho.  Isto quer dizer que podemos especificar um subdiretório
+      com uma política de acesso diferente para Sally:</para>
 
     <screen>
 [calc:/branches/calc/bug-142]
 harry = rw
 sally = r
 
-# give sally write access only to the 'testing' subdir
+# dá à sally acesso de escrita apenas no subdiretório 'testing'
 [calc:/branches/calc/bug-142/testing]
 sally = rw
 </screen>
 
-    <para>Now Sally can write to the <filename>testing</filename>
-      subdirectory of the branch, but can still only read other parts.
-      Harry, meanwhile, continues to have complete read-write access
-      to the whole branch.</para>
-
-    <para>It's also possible to explicitly deny permission to someone
-      via inheritance rules, by setting the username variable to
-      nothing:</para>
+    <para>Agora Sally pode escrever no subdiretório
+      <filename>testing</filename> do ramo, mas ainda continua tendo
+      acesso somente leitura a outras partes.  Harry, no entanto,
+      continua a ter acesso completo de leitura/escrita ao ramo
+      inteiro.</para>
+
+    <para>Também é possível negar permissão a alguns usuários através das
+      regras de herança, removendo o valor da variável do nome do
+      usuário:</para>
 
     <screen>
 [calc:/branches/calc/bug-142]
@@ -2585,50 +2591,50 @@
 harry =
 </screen>
 
-    <para>In this example, Harry has read-write access to the
-      entire <filename>bug-142</filename> tree, but has absolutely no
-      access at all to the <filename>secret</filename> subdirectory
-      within it.</para>
-
-    <para>The thing to remember is that the most specific path always
-      matches first.  The server tries to match the path itself, and
-      then the parent of the path, then the parent of that, and so on.
-      The net effect is that mentioning a specific path in the
-      accessfile will always override any permissions inherited from
-      parent directories.</para>
-
-    <para>By default, nobody has any access to the repository at all.
-      That means that if you're starting with an empty file, you'll
-      probably want to give at least read permission to all users at
-      the root of the repository.  You can do this by using the
-      asterisk variable (<literal>*</literal>), which means <quote>all
-      users</quote>:</para>
+    <para>Neste exemplo, Harry tem acesso completo leitura/escrita à toda
+      a árvore <filename>bug-142</filename>, mas não tem absolutamente
+      nenhum acesso em todo o subdiretório <filename>secret</filename>
+      dentro dela.</para>
+
+    <para>O que você deve lembrar é que a correspondência sempre é feita
+      com os caminhos mais específicos primeiro.  O servidor tenta achar
+      uma ocorrência com o próprio caminho, então depois com o caminho do
+      diretório pai, e depois com o pai deste, e assim por diante.  O
+      efeito em rede é que mencionando um caminho específico no arquivo
+      de acesso sempre irá sobrescrever qualquer permissão herdada dos
+      diretórios pais.</para>
+
+    <para>Por padrão, ninguém tem acesso ao repositório como um todo.
+      Isto significa que se você está iniciando com um arquivo vazio,
+      você provavelmente quer pelo menos dar permissão de leitura a todos
+      os usuários na raiz do repositório.  Você pode fazer isso usando a
+      variável asterisco (<literal>*</literal>), o que quer dizer
+      <quote>todos os usuários</quote>:</para>
 
     <screen>
 [/]
 * = r
 </screen>
 
-    <para>This is a common setup; notice that there's no repository
-      name mentioned in the section name.  This makes all repositories
-      world readable to all users. Once all users have read-access to
-      the repositories, you can give explicit
-      <literal>rw</literal> permission to certain users on specific
-      subdirectories within specific repositories.</para>
-
-    <para>The asterisk variable (<literal>*</literal>) is also worth
-      special mention here: it's the
-      <emphasis>only</emphasis> pattern which matches an anonymous
-      user.  If you've configured your server block to allow a mixture
-      of anonymous and authenticated access, all users start out
-      accessing anonymously.  The server looks for a
-      <literal>*</literal> value defined for the path being accessed;
-      if it can't find one, then it demands real authentication from
-      the client.</para>
-
-    <para>The access file also allows you to define whole groups of
-      users, much like the Unix <filename>/etc/group</filename>
-      file:</para>
+    <para>Esta é uma configuração comum; note que não aparece o nome de
+      nenhum repositório no nome da seção.  Isto torna todos os
+      repositórios legíveis para todos os usuários.  Uma vez ue todos os
+      usuários tem acesso de leitura aos repositórios, você pode dar
+      permissões <literal>rw</literal> explícitas a certos usuários em
+      subdiretórios dentro de repositórios específicos.</para>
+
+    <para>A variável asterisco (<literal>*</literal>) merece também um
+      destaque especial aqui: é o <emphasis>único</emphasis> padrão que
+      corresponde com o usuário anônimo.  Se você configurou seu bloco
+      servidor para permitir um misto de acesso anônimo e autenticado,
+      todos os usuários iniciam acessando anonimamente.  O servidor
+      procura por um valor <literal>*</literal> definido para o caminho
+      sendo acessado; se encontrar, então requisita autenticação efetiva
+      do cliente.</para>
+
+    <para>O arquivo de acesso também lhe possibilita definir grupos
+      inteiros de usuários, tal como o arquivo 
+      <filename>/etc/group</filename> do Unix:</para>
 
     <screen>
 [groups]
@@ -2637,9 +2643,10 @@
 everyone = harry, sally, joe, frank, sally, jane
 </screen>
 
-    <para>Groups can be granted access control just like users.
-      Distinguish them with an <quote>at</quote>
-      (<literal>@</literal>) prefix:</para>
+    <para>Controle de acesso pode ser definido para grupos da mesma forma
+      como para usuários.  Sendo que os grupos se distinguem por tem um
+      sinal de <quote>arroba</quote> (<literal>@</literal>) na
+      frente:</para>
 
     <screen>
 [calc:/projects/calc]
@@ -2650,7 +2657,8 @@
 jane = r
 </screen>
 
-    <para>Groups can also be defined to contain other groups:</para>
+    <para>Grupos também podem ser definidos de forma a conter outros
+      grupos:</para>
 
     <screen>
 [groups]
@@ -2659,35 +2667,35 @@
 everyone = @calc-developers, @paint-developers
 </screen>
 
-  <!-- TODO(sussman):  this sidebar needs to be changed for svn 1.5,
-  making it clear that it's a neon behavior, and ??probably?? not the
+  <!-- TODO(sussman):  this sidebar needs to be changed for svn 1.5
+  making it clear that it's a nenon behavior, and ??probably?? not the
   case when using serf... -->
   <sidebar>
-    <title>Partial Readability and Checkouts</title>
+    <title>Legibilidade Parcial e Checkouts</title>
 
-    <para>If you're using Apache as your Subversion server and have
-      made certain subdirectories of your repository unreadable to
-      certain users, then you need to be aware of a possible
-      non-optimal behavior with <command>svn
+    <para>Se você está usando o Apache como seu servidor Subversion e
+      deixou determinados subdiretórios de seu repositório ilegíveis para
+      certos usuários, então você precisa ter cuidado com um
+      possível comportamento não-otimizado do comando <command>svn
       checkout</command>.</para>
 
-    <para>When the client requests a checkout or update over HTTP, it
-      makes a single server request, and receives a single (often
-      large) server response.  When the server receives the request,
-      that is the <emphasis>only</emphasis> opportunity Apache has to
-      demand user authentication.  This has some odd side-effects.
-      For example, if a certain subdirectory of the repository is only
-      readable by user Sally, and user Harry checks out a parent
-      directory, his client will respond to the initial authentication
-      challenge as Harry.  As the server generates the large response,
-      there's no way it can re-send an authentication challenge when
-      it reaches the special subdirectory;  thus the subdirectory is
-      skipped altogether, rather than asking the user to
-      re-authenticate as Sally at the right moment.  In a similar way,
-      if the root of the repository is anonymously world-readable,
-      then the entire checkout will be done without
-      authentication—again, skipping the unreadable directory,
-      rather than asking for authentication partway through.</para>
+    <para>Quando o cliente realiza um checkout ou update sobre HTTP, ele
+      faz uma única requisição ao servidor, e recebe uma única resposta
+      (quase sempre bem grande).  Quando o servidor recebe a requisição,
+      que é a <emphasis>única</emphasis> oportunidade que o Apache tem de
+      solicitar autenticação do usuário.  Isto tem alguns efeitos
+      colaterais.  Por exemplo, se um certo determinado subdiretório do
+      repositório é legível apenas pelo usuário Sally, e o usuário Harry
+      dá um checkout num diretório pai, seu cliente vai atender ao
+      desafio de autenticação inicial como Harry.  Como o servidor gera
+      uma resposta grande, não há uma forma de re-enviar um desafio de
+      autenticação quando encontrar um subdiretório especial; pulando
+      assim este subdiretório como um todo, em vez de solicitar que o
+      usuário se re-autentique como Sally no momento certo.  De maneira
+      similar, se a raiz do repositório é legível anonimamente por todos,
+      então todo checkout será feito sem autenticação—novamente,
+      pulando o diretório legível em vez de solicitar autenticação para
+      ter acesso a essas partes do repositório.</para>
   </sidebar>
 
   </sect1>




More information about the svn-pt_br mailing list