Su, sux, sudo, sudoers e as permissões

O Linux nasceu como um sistema multiusuário, mantendo a tradição dos sistemas Unix. Ele oferece um sistema de permissões bastante simples, porém ao mesmo tempo bastante efetivo, atendendo tanto a desktops domésticos, usados por apenas duas ou três pessoas, quanto servidores com centenas de usuários.

No Linux, o root é o único que tem acesso a todos os arquivos e configurações do sistema. Os usuários normais têm, por padrão, acesso apenas a seus arquivos dentro do diretório /home e alguns outros arquivos específicos. Em um desktop, a idéia básica é que você use um login normal de usuário para rodar programas e executar as tarefas do dia-a-dia e logue-se como root quando precisar instalar programas ou alterar a configuração do sistema.

Todos os programas salvam suas configurações dentro de pastas ocultas, dentro do diretório home, como a “.gnome2”, que armazena a maior parte das configurações relacionadas ao Gnome e a “.kde”, que guarda as configurações do KDE e dos aplicativos baseados nele. Cada usuário tem suas próprias pastas de configuração e pode alterar apenas seus próprios arquivos, o que evita confusão em PCs ou servidores compartilhados entre vários usuários. O máximo que poderia acontecer seria um usuário deletar seus próprios arquivos, ou bagunçar suas próprias configurações.

Em qualquer distribuição, você pode se logar como root usando o comando “su” no terminal, fornecendo a senha de root. De uma forma geral, recomenda-se usá-lo com o parâmetro “-“, que atualiza as variáveis de ambiente:

$ su –

O símbolo do terminal muda de um “$” para um “#”, indicando que a partir daí, todos os comandos digitados nesse terminal específico serão executados como root.

Um problema comum é que você não consiga rodar aplicativos gráficos depois de logado como root, recebendo um “konqueror: cannot connect to X server ” ou um “Error: no display specified “. Isso acontece por que, na maioria das distribuições, as permissões do X não são atualizadas, fazendo com que, por paradoxal que possa parecer, o root não tenha permissão para usar o ambiente gráfico. Isso acaba sendo um grande empecilho, já que você não pode usar editores de texto como o gedit ou o kwrite para editar arquivos de configuração, por exemplo.

A solução mais simples é instalar o pacote “sux” e passar a usar o comando no lugar do su. O “sux” atualiza as permissões do ambiente gráfico, solucionando o problema. Basta passar a usá-lo no lugar do “su” quando quiser rodar aplicativos gráficos:

$ sux

Outra opção é rodar os programas gráficos usando o “gksu” (no Gnome) ou o “kdesu” (no KDE), seguidos do comando desejado, como em:

$ gksu gedit

ou:

$ kdesu konqueror /etc

Assim como no caso do sux, eles ajustam as permissões do X automaticamente. Uma forma prática de usá-los é rodar os comandos usando o Alt+F2.

As distribuições atuais têm cada vez mais adotado o uso do “sudo“, como uma forma de facilitar o uso do sistema, permitindo que você execute aplicativos como root quando precisar.

Muita gente associa o uso do sudo ao Ubuntu, mas ele na verdade começou a ser usado em larga escala um pouco antes, no Knoppix e em outros live-CDs baseados nele, como o Kurumin. No caso dos live-CDs, o sudo é usado como um facilitador, para permitir que o sistema permita a execução de comandos como root sem que seja preciso definir uma senha default para o root. Quando você precisa abrir uma janela do gerenciador de arquivos como root, para recuperar arquivos dentro de uma partição do HD, por exemplo, você precisa apenas chamá-lo colocando um sudo antes do comando, como em:

$ sudo konqueror /mnt/sda2

O sudo pode ser usado até mesmo para alterar a senha de root, permitindo que você defina uma senha para o live-CD, mesmo sem saber a senha anterior:

$ sudo passwd

O Ubuntu (depois de instalado) usa uma abordagem mais conservadora, confirmando sua senha de usuário antes de executar o comando. Essa é uma precaução básica de segurança, que evita que alguém possa alterar a senha de root e assumir o controle do seu PC enquanto você estiver tomando um cafezinho, por exemplo.

Em qualquer um dos casos, a configuração do sudo vai no arquivo “/etc/sudoers“, onde são especificados os usuários que poderão usar o sudo. No Ubuntu, por exemplo, é usada a seguinte configuração:

%admin ALL=(ALL) ALL

O “%admin” indica que a regra não se aplica a um usuário específico, mas sim a todos os usuários que fazem parte do grupo “admin”. Por default, apenas o usuário criado durante a instalação faz parte do grupo e apenas ele poe usar o sudo, mas você pode criar outros usuários administrativos posteriormente simplesmente adicionando-os ao grupo, como em:

# addgroup gdh admin

Devido ao “ALL=(ALL) ALL “, o sistema permite que o sudo seja usado para executar qualquer comando (com algumas poucas exceções) mas apenas depois de confirmada a senha do usuário.

Para poder executar comandos sem precisar confirmar a senha (como ao rodar usando o live-CD), você precisaria apenas alterar a linha, substituindo o “(ALL)” por um “NOPASSWD:”, como em:

%admin ALL=NOPASSWD: ALL

No caso do Ubuntu, o arquivo vem com uma linha “%sudo ALL=NOPASSWD: ALL” comentada, que tem um efeito semelhante, permitindo que os usuários incluídos no grupo “sudo” possam usar o sudo sem senha.

Por ser um arquivo essencial dentro do sistema de permissões do sistema, o “/etc/sudoers” é um arquivo extremamente sensível. Qualquer erro dentro da configuração, ou qualquer alteração nas permissões do arquivo (que devem ser, obrigatoriamente, “0440”) fazem com que o sudo deixe de funcionar, bloqueando parcialmente o sistema até que o problema seja resolvido.

É por isso que é recomendado que você edite o arquivo usando o comando “visudo”, que não permite que você salve o arquivo caso existam erros na configuração. O grande problema é que ele é complicado de usar, o que faz com que muitos dispensem o conselho e usem outros editores de texto. Não existe nada de errado nisso, desde que você cheque e recheque a configuração antes de salvar.

Outra dica é que você sempre destrave a conta de root usando o “sudo passwd” antes de tentar editar o arquivo. Isso garante que você continue conseguindo se logar como root no sistema caso o sudo fique travado por um erro na configuração do arquivo.

Em seguida, temos a questão das permissões. Clicando sobre as propriedades de qualquer pasta ou arquivos dentro do gerenciador de arquivos, você encontra um menu com o ajuste de permissões, onde pode ajustar individualmente as permissões para o dono do arquivo, para usuários que façam parte do mesmo grupo e para os outros, que inclui todos os demais usuários com acesso ao sistema:

Cada um dos campos aceita três possibilidades: “Nenhum”, “Apenas leitura” e “Leitura e escrita”. Por default, o dono é o único que pode ler e escrever, os demais (grupo e outros) podem apenas ler o arquivo, sem modificá-lo.

No caso dos arquivos, existe uma quarta permissão que é o campo “Permitir execução do arquivo como um programa”. Esta é uma daquelas diferenças fundamentais entre o Linux e o Windows: o sistema não decide quais arquivos são programas pela extensão, mas sim pelas permissões. Isso aumenta bastante a segurança do sistema, mas, por outro lado, causa um pouco de dor de cabeça em algumas situações. Sempre que você baixar um instalador qualquer via web (o driver da nVidia, por exemplo), vai precisar primeiro ativar a permissão de execução nas propriedades do arquivo antes de conseguir instalá-lo.

O “dono” do arquivo é por default o usuário que criou o arquivo. Apenas este usuário pode alterar as permissões de acesso ao arquivo e pasta. Em seguida vem a configuração do grupo, que permite que vários usuários tenham acesso a um arquivo ou pasta, sem ter que apelar para o campo “outros” que daria acesso a qualquer um.

Nesse caso, você criaria um novo grupo, adicionaria a ele os usuários que devem ter acesso e em seguida alteraria as permissões de acesso, de forma que o grupo passasse a ser dono da pasta e os integrantes pudessem ter e alterar os arquivos.

Você pode criar novos grupos e adicionar usuários a eles através do “users-admin” (“Sistema > Administração > Usuários e Grupos”, nas distribuições derivadas do Gnome), ou usando outra ferramenta gráfica incluída na distribuição, como o UserDrake, disponível no Mandriva ou o Kuser.

Para criar um novo grupo, clique em “Gerenciar Grupo > Adicionar Grupo”. Na janela que será aberta, especifique o nome do grupo e os usuários que farão parte dele. Um mesmo usuário pode fazer parte de vários grupos simultaneamente. Muita gente cria um grupo diferente para cada pasta importante, de forma a poder definir individualmente quem terá acesso a ela.

Você notará que nesta tela aparecem vários usuários que não são mostrados na tela principal, como o “bin”, “daemon” e “mail”. Estes são usuários ocultos do sistema, contas sem privilégios e que não possuem senhas definidas (é simplesmente impossível fazer login com qualquer uma delas), que são usadas para isolar os programas, fazendo com que cada um tenha acesso apenas a seus próprios arquivos. Isso limita muito os danos que um programa ou servidor com bugs ou falhas de segurança pode causar quando alguma coisa dá errado.

De fato, a configuração default da maior parte das distribuições Linux atuais é dar acesso de leitura para a maioria das pastas (com exceção, naturalmente, dos arquivos de senha e outros arquivos críticos do sistema) para todos os usuários, mas ao mesmo tempo dar acesso de gravação apenas para o diretório home de cada um.

Por default, o único que pode alterar o dono das pastas é o próprio root (os usuários podem alterar apenas o grupo e ainda assim apenas entre os grupos de que fazem parte). Um dos motivos para isso é o suporte a quotas, que (embora não seja muito usado em desktops) está disponível em qualquer distribuição Linux. Se qualquer usuário pudesse alterar a posse dos arquivos, transferindo-os para outros usuários, o sistema de quotas seria muito fácil de burlar.

A forma mais simples de alterar os donos e grupos dos arquivos e pastas é simplesmente abrir uma janela do gerenciador de arquivos como root, como em:

$ gksu nautilus

Diferente do que temos ao rodar o gerenciador como usuário, ao acessar as propriedades dos arquivos como root os campos do dono e do grupo ficam desbloqueados, permitindo que você ajuste as permissões livremente.

Como de praxe, você pode também ajustar as permissões via linha de comando, usando os comandos “chmod” e “chown“. O primeiro permite ajustar as permissões dos arquivos e pastas, enquanto o segundo permite transferir a posse, dizendo a qual usuário e a qual grupo determinada pasta ou arquivo pertence.

Um exemplo comum é quando você cria ou copia uma pasta como root e devido a isso fica sem poder modificar os arquivos usando seu login de usuário. Uma maneira simples de resolver o problema seria usar o comando “chown” (como root) para transferir a posse da pasta, como em:

# chown -R gdh /home/gdh/arquivos/

O “-R” no comando faz com que ele seja recursivo, ou seja, altere as permissões não apenas da pasta, mas de todo o conteúdo. Sem ele, você passaria a conseguir escrever dentro da pasta, mas ainda continuaria sem acesso às subpastas dentro dela. Em seguida, temos o “gdh”, que indica o usuário e a pasta que será modificada.

Outro uso comum é especificar também o grupo, como em:

# chown -R gdh:gdh /home/gdh/arquivos/

Você pode também criar novos usuários e alterar as senhas usando o “adduser” e o “passwd“, que permitem, respectivamente, adicionar novos usuários e alterar as senhas de acesso posteriormente, como em:

# adduser joao
(cria o usuário)

# passwd joao
(altera a senha posteriormente)

O próprio usuário pode alterar a senha usando o comando “passwd”, desde que ele saiba a senha antiga. Se o usuário esqueceu a senha, você pode definir uma nova executando o comando como root; nesse caso o sistema pede a nova senha diretamente, sem solicitar a senha antiga.

Bem antigamente, as senhas eram salvas no próprio arquivo “/etc/passwd”, juntamente com as demais informações, o que abria brecha para diversos tipos de ataques. A partir de um certo ponto (por volta de 1996), todas as distribuições passaram a utilizar o sistema shadow, onde as senhas são armazenadas de forma encriptada em um arquivo separado, o “/etc/shadow”.

As senhas são encriptadas usando um algoritmo de mão única, que permite apenas encriptar as senhas, mas não recuperá-las. Durante o login, o sistema aplica o mesmo algoritmo à senha digitada pelo usuário e compara a string resultante com a armazenada no arquivo. Se o resultado for o mesmo, o sistema sabe que a senha confere e o acesso é autorizado.

Para remover um usuário anteriormente criado, utilize o comando “deluser“, como em:

# deluser joao

Por questão de segurança, o comando remove apenas a conta, sem apagar o diretório home ou outras pastas com dados do usuário (como o diretório de spool dos e-mails). O diretório home é especialmente importante, pois ele guarda todas as configurações e os arquivos do usuário, de forma que em um servidor você só deve removê-lo depois de ter realmente certeza do que está fazendo.

Concluindo, você pode alterar as permissões de acesso de arquivos e pastas usando o comando chmod. A sintaxe dele parece um pouco complicada à primeira vista (justamente por isso a maioria acaba preferindo usar diretamente o gerenciador de arquivos), mas nada que um pouco de prática não possa resolver.

Um exemplo típico seria:

# chmod 744 arquivo

Os três números indicam respectivamente as permissões para o dono do arquivo, as permissões para o grupo e as permissões para os demais usuários.

Temos três permissões: leitura, gravação e execução. Cada uma é representada por um número:

4: Ler.
2: Alterar o conteúdo, criar novos arquivos (no caso de uma pasta).
1: Execução (no caso dos arquivos) ou listar os arquivos (no caso das pastas).

Você simplesmente soma estes números para ter o número referente ao conjunto de permissões que deseja:

0: Sem permissão alguma. Se for uma pasta, o usuário sequer pode ver o conteúdo.
1: Permissão apenas para executar (não é possível ler o arquivo ou alterá-lo, apenas executar um programa). No caso de uma pasta, o “1” permite que se liste os arquivos dentro dela, mas sem ler ou alterar os arquivos.
4: Apenas leitura.
5 (4+1): Ler e executar (no caso de um arquivo) ou ver os arquivos e abri-los, no caso de uma pasta.
6 (4+2): Leitura + gravação.
7 (4+2+1): Controle total: leitura + gravação + permissão para executar.

Uma observação importante é que ao configurar as permissões de acesso de uma pasta, você sempre deve usar 5 (4+1) ou 7 (4+2+1), pois, sem permissão para listar o conteúdo da pasta, você não consegue ver os arquivos dentro dela.

Se você quer dar controle total do arquivo ou pasta para o dono e para o grupo, mas permissão de apenas leitura para os demais usuários, usaria o número 774; se você quisesse que todos os usuários tivessem permissão de leitura e gravação, mas sem poder executar nada, usaria o número 666; se quisesse dar controle total para todo mundo, usaria 777 e assim por diante.