← Back to branch summary

~ubuntu-branches/ubuntu/wily/kde-l10n-ptbr/wily

« back to all changes in this revision

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

  • Committer: Package Import Robot
  • Author(s): Jonathan Riddell
  • Date: 2015-01-21 12:33:46 UTC
  • mfrom: (1.12.49)
  • Revision ID: package-import@ubuntu.com-20150121123346-cz24qse1vtmuvdhu
Tags: 4:14.12.2-0ubuntu1
* New upstream release, first version from KDE Applications
* Revert install to /usr/share/locale/
* Add debian/overlapping files to remove files that are in plasma5

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/kde-workspace/PolicyKit-kde/howitworks.docbook
1
 
<chapter id="howitworks">
2
 
<title
3
 
>Como funciona</title>
4
 
 
5
 
<sect1 id="howitworks-overview">
6
 
<title
7
 
>Resumo</title>
8
 
 
9
 
<para
10
 
>O PolicyKit tem um jeito simples de funcionar, mas requer algumas alterações de design dos aplicativos que queiram usá-lo para requisitar senhas.</para>
11
 
</sect1>
12
 
 
13
 
<sect1 id="howitworks-problem">
14
 
<title
15
 
>O problema</title>
16
 
 
17
 
<para
18
 
>Nos aplicativos gráficos, 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 além disso não permitir um bom mapeamento das ações. Não existe uma forma de separar as ações como a instalação de pacotes e uma atualização do sistema. Todos os usuários que desejarem realizar estas ações deverão possuir a senha de 'root'. Outra abordagem comum é usar o 'sudo' mas, assim que iniciar um aplicativo com o 'sudo', irá obter todas as permissões que o usuário de 'root' tiver. Se, por exemplo, o aplicativo gráfico tiver uma janela para selecionar os arquivos, essa janela irá rodar como 'root', o que significa que o usuário conseguirá apagar qualquer arquivo na sua máquina ou mesmo copiar os arquivos dos outros usuários. </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 é resolvido. O aplicativo em questão só precisa de separar o código privilegiado para outro aplicativo, chamado de 'auxiliar' (que não terá nenhuma interface gráfica) e depois mapeia as ações desejadas num arquivo <quote
27
 
>.policy</quote
28
 
>. O PolicyKit irá então carregar este arquivo e poderá em seguida autenticar os aplicativos que usarem estas ações. O uso dos aplicativos ativados pelo &DBus; é a melhor, se não a única, forma de colocar um aplicativo auxiliar em execução com privilégios de 'root'.</para>
29
 
 
30
 
<para
31
 
>Com este desenho, o aplicativo gráfico invoca uma ação do aplicativo auxiliar, através do &DBus;, que irá então iniciar o programa auxiliar com privilégios de 'root', informando-o da ação que foi pedida e qual o aplicativo que a pediu. O aplicativo auxiliar poderá então invocar o agente do PolicyKit para ver se esse aplicativo pode efetuar a tarefa indicada. No caso de o programa auxiliar ver que o aplicativo não possui permissão suficiente, 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, o aplicativo gráfico necessita invocar o programa auxiliar, repetindo a mesma operação novamente.</para>
35
 
</sect1>
36
 
 
37
 
</chapter>