~ubuntu-branches/ubuntu/oneiric/kde-l10n-pt/oneiric

« back to all changes in this revision

Viewing changes to docs/kdebase-workspace/PolicyKit-kde/howitworks.docbook

  • Committer: Bazaar Package Importer
  • Author(s): Harald Sitter
  • Date: 2010-09-02 12:03:13 UTC
  • mto: This revision was merged to the branch mainline in revision 41.
  • Revision ID: james.westby@ubuntu.com-20100902120313-ti3spteycb0rz19n
Tags: upstream-4.5.1
Import upstream version 4.5.1

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
<chapter id="howitworks">
 
2
<title
 
3
>Como funciona</title>
 
4
 
 
5
<sect1 id="howitworks-overview">
 
6
<title
 
7
>Introdução</title>
 
8
 
 
9
<para
 
10
>O PolicyKit tem uma forma simples de trabalhar, mas necessita de algumas alterações no desenhado das aplicações que o desejam usar para pedir senhas.</para>
 
11
</sect1>
 
12
 
 
13
<sect1 id="howitworks-problem">
 
14
<title
 
15
>O problema</title>
 
16
 
 
17
<para
 
18
>Nas aplicações gráficas, a forma comum de ganhar privilégios de 'root' é iniciá-las como 'root', mas existem diversos riscos de segurança ao usar este método e também permite um bom mapeamento das acções. Não existe uma forma de separar as acções como a instalação de pacotes e uma actualização do sistema. Todos os utilizadores que quiserem usá-la deverão ter a senha de 'root'. Outra abordagem comum é usar o 'sudo' mas, assim que iniciar uma aplicação com o 'sudo', irá ter todas as permissões que o utilizador de 'root' tiver. Se, por exemplo, a aplicação gráfica tiver uma janela para seleccionar os ficheiros, essa janela irá correr como 'root', o que significa que o utilizador conseguir apagar qualquer ficheiro na sua máquina ou mesmo copiar os ficheiros dos outros utilizadores. </para>
 
19
</sect1>
 
20
 
 
21
<sect1 id="howitworks-solution">
 
22
<title
 
23
>A solução</title>
 
24
 
 
25
<para
 
26
>Com o PolicyKit, este problema fica resolvido. A aplicação em questão só precisa de separar o código privilegiado para outra aplicação, chamada de 'auxiliar' (que não terá nenhuma interface gráfica) e depois mapeia as acções desejadas num ficheiro <quote
 
27
>.policy</quote
 
28
>. O PolicyKit irá então carregar este ficheiro e poderá a seguir autenticar as aplicações que usarem estas acções. A utilização das aplicações activadas por &DBus; é a melhor, se não a única, forma de colocar uma aplicação auxiliar em execução com privilégios de 'root'.</para>
 
29
 
 
30
<para
 
31
>Com este desenho, a aplicação gráfica invoca uma acção da aplicação auxiliar, através do &DBus;, que irá então iniciar o programa auxiliar com privilégios de 'root', informando-o da acção que foi pedida e qual a aplicação que a pediu. A aplicação auxiliar poderá então invocar o agente do PolicyKit para ver se essa aplicação pode efectuar a tarefa indicada. No caso de o programa auxiliar ver que a aplicação não tinha permissões suficientes, a interface irá então necessitar de pedir ao PolicyKit para obter uma autorização.</para>
 
32
 
 
33
<para
 
34
>Quando o PolicyKit receber o pedido de obtenção de autorização, irá comunicar com um agente disponível, o qual poderá ser o &policykit-kde;, se estiver disponível. Depois de uma autenticação bem-sucedida, a aplicação gráfica necessita de invocar o programa auxiliar, repetindo a mesma operação de novo.</para>
 
35
</sect1>
 
36
 
 
37
</chapter>