<para>Esta secção é principalmente para os super-utilizadores (o <systemitem>root</systemitem>) com grandes necessidades de segurança, ou simplesmente para as pessoas interessadas tecnicamente. Não é necessário ler isto se você usa o &Linux; em casa para si, ainda que possa aprender uma ou duas coisas, de qualquer forma.</para>
<para>Um administrador de sistemas poderá querer restringir o acesso às pessoas que têm permissão para usar o &kppp;. Existem duas formas de o conseguir.</para>
<title>Restringir o acesso com as permissões do grupo</title>
<para>Crie um novo grupo (você poderá querer chamar-lhe <systemitem>ligacao</systemitem> ou algo do género), e colocar todos os utilizadores que poderão usar o &kppp; nesse grupo. A partir daí, escreva na linha de comandos:</para>
<para>Isto irá assumir que o &kde; foi instalado em <filename class="directory"> /opt/kde/</filename> e que o seu grupo se chama <systemitem>ligacao</systemitem>.</para>
<title>Restringir a forma de acesso do &kppp;</title>
<para>Antes de fazer algo, o &kppp; verifica se existe um ficheiro chamado <filename>/etc/kppp.allow</filename>. Se existir, só os utilizadores indicados neste ficheiro poderão estabelecer a ligação. Este ficheiro deverá ser legível por todos (mas obviamente <emphasis>NÃO</emphasis> poderá ter permissões de escrita.) Só os nomes dos utilizadores serão reconhecidos, por isso você não poderá usar os <acronym>UID</acronym>'s neste ficheiro. Aqui está um pequeno exemplo:</para>
<para>No exemplo acima, só os utilizadores <systemitem>ze</systemitem>, <systemitem>pedro</systemitem> e <systemitem>manel</systemitem> é que têm permissões para estabelecer a ligação, assim como todos os utilizadores com um <acronym>UID</acronym> igual a 0 (por isso, você não terá de pôr explicitamente o 'root' nesse ficheiro).</para>
<para>É virtualmente possível criar um activador de ligações sem o 'bit' <acronym>SUID</acronym> activo e que seja tanto seguro como simples de usar por utilizadores pouco experientes. O &kppp; trata das questões de segurança com a seguinte estratégia.</para>
<para>O processo-pai, que trata de todas as operações de <acronym>GUI</acronym> (como a interacção com o utilizador), descarta o estado <acronym>SUID</acronym> a seguir ao 'fork', e corre com permissões de utilizador normal.</para>
<para>O processo-filho mantém os seus privilégios e é responsável por todas as acções que necessitem de privilégios do <systemitem>root</systemitem>. Para manter esta parte segura, não são usadas chamadas de bibliotecas do &kde; ou do &Qt; aqui, somente chamadas de bibliotecas simples. O código-fonte para este processo é pequeno (à volta de 500 linhas) e está bem documentado, por isso é fácil detectar nele falhas de segurança.</para>
<para>Muito obrigado ao Harri Porten por ter escrito este pedaço excelente de código. Pensou-se que seria impossível, mas ele conseguiu fazê-lo numa semana.</para>