Permissões especiais: stick e suid bit

No post anterior, falei sobre a umask para definir permissão padrão para criação de novos arquivos e diretórios. E ainda estou devendo as duas permissões especiais stick bit e suid bit.

Estamos lá, felizes da vida como adm da Zion… quando o neo, por descuido apagou um arquivo da trinity:

$ rm report.txt
rm: remover arquivo comum vazio `report.txt’? y
`report.txt’ removido

Hmm… isso não é bom. Usuários apagando arquivos de outros… não é legal. Então, como adm, vamos resolver esse problema usando a permissão especial stick bit.

A permissão stick bit em um diretório faz com que só o dono do arquivo e somente ele apague o arquivo que ele criou! Um exemplo de diretório que usa essa permissão, é o /tmp. Vejam:

# ls -ld /tmp/
drwxrwxrwt 4 root root 4096 Mai 15 21:39 /tmp/

Reparem o ‘t‘ no lugar do ‘x‘ no bloco de permissão de outros… esse ‘t’ indica que a permissão stick bit esta ativa para o diretório… e ai, só quem for o dono do arquivo poderá apagar o arquivo que criou!

No nosso caso, vamos aplicar então, a permissão stick bit ao diretório private… pra evitar que o neo apague outro arquivo da trinity… ou então ela por vingança apague um arquivo do neo 😛 .

# cd /mnt

# chmod +t private/

# ls -l
total 8
drwxr-xr-x 2 root generics 4096 Mai 15 21:21 generics
drwxrws–T 2 root private  4096 Mai 16 11:52 private

Acima, so pedimos para acrescentar a permissão stick bit para todos os blocos de permissão (dono, grupo e outros) utilizando a forma literal… se fosse utilizar a forma octal, o comando seria:

# chmod 3770 private/

Acima, colocamos o 3 porque já existe a permissão de sgid bit que tem o valor 2… e precisamos acrescentar a permissão stick bit que tem valor 1. E temos também que acrescentar as demais permissões que já existiam para o diretório (770).

Vocês devem ter reparado que tem uma diferença entre o stick bit do diretório /tmp e do /mnt/private:

# ls -ld /tmp/
drwxrwxrwt 4 root root 4096 Mai 15 21:39 /tmp/

# ls -ld /mnt/private/
drwxrws–T 2 root private 4096 Mai 16 11:53 /mnt/private/

Essa diferença entre os t’s nos diretórios é que, quando não tem permissão no bloco de outros, a stick bit é indica com o T maiúsculo; e quando existe permissão no bloco de outros, é indicada com t minúsculo.

Vamos ver se isso funciona… a trinity criou o arquivo reports2.txt e o neo, tenta apagar:

$ rm reports2.txt
rm: remover arquivo comum vazio `reports2.txt’? y
rm: imposível remover `reports2.txt’: Operação não permitida

Bem… com isso vimos que a stick bit funciona!

Falando agora sobre a permissão especial suid bit… ela é uma permissão utilizada em arquivos executáveis! Sua função é permitir que um usuário que não seja o dono do arquivo execute como se fosse o dono!

Por exemplo… no terminal que estamos logados como trinity, executamos o comando init, que é o comando que manipula o runlevel do sistema:

$ init
-su: init: command not found

Vejam que a saída do comando é not found… O init é um comando de administração do sistema e a única pessoa que pode executar esse comando é root! Vamos ver como está a permissão do comando init:

# ls -l /sbin/init
-rwxr-xr-x 1 root root 31296 Ago 12  2008 /sbin/init

A permissão padrão desse comando está como 755… vamos adicionar a permissão de suid bit:

# chmod u+s /sbin/init

# ls -l /sbin/init
-rwsr-xr-x 1 root root 31296 Ago 12  2008 /sbin/init

Acima, usei o modo literal para definir a permissão de suid… como é uma permissão para usuários… acrescentamos somente a permissão o bloco de permissão do usuário. Reparem no ‘s’ no local do ‘x’ para execução do comando.

Se fosse para definir a permissão em modo octal, o suid tem valor 4, então ficaria assim:

# chmod 4755 /sbin/init

Sendo que o 4 indica que é permissão do suid, e 755 são as permissões originais do arquivo.

Agora, se a trinity for fazer um teste… se digitar somente o comando init, irá aparecer not found novamente… mas se ela informar o caminho completo do arquivo, vejam o que acontece:

$ /sbin/init
Usage: init {-e VAR[=VAL] | [-t SECONDS] {0|1|2|3|4|5|6|S|s|Q|q|A|a|B|b|C|c|U|u}}b

Hummm… se a trinity executar o comando de forma certa, agora ela também pode manipular o runlevel do sistema…

Vamos voltar o arquivo para a permissão original:

# chmod u-s /sbin/init

# ls -l /sbin/init
-rwxr-xr-x 1 root root 31296 Ago 12  2008 /sbin/init

Usando a forma literal, basta retirar a permissão… se for usar a forma octal:

# chmod 0755 /sbin/init

O exemplo que coloquei, foi apenas para mostrar que arquivos com permissão suid da poderes que talvez não devam ser dados para qualquer usuário… Imaginem, um agente smith, com poderes para manipular o runlevel do sistema?

Mas ainda assim, no sistema existem alguns comandos que precisam de suid e já vem até setado por padrão no sistema. Um exemplo, é o comando passwd que permite que o usuário troque sua própria senha:

# ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 31640 Nov 22 14:01 /usr/bin/passwd

Se retirarmos o suid desse comando, somente o root poderá trocar a senha dos usuários, o que pode não ser tão conveniente…

Para descobrir quais arquivos estão com suid no sistema, podemos usar o find:

# find / -perm +4000

Com a lista dos comandos, você como adm, pode definir quais arquivos realmente tem necessidade de ter suid, e também se algum usuário mal-intencionado não colocou nenhum arquivo com suid que possa ser prejudicial ao sistema!

É isso aí… com os comandos que vimos nos posts de administração de usuários e permissões… já conseguimos colocar um pouco de ordem no sistema! Até o próximo post!

Anúncios

Permissões x umask

Como disse no post anterior, umask é a permissão padrão para criação de arquivos e diretórios; isto é… quando criamos um arquivo ou um diretório no sistema, estes já vem com uma permissão padrão.

Todo usuário tem um valor de umask, que define a permissão padrão para criação de arquivos e diretórios. O comando para visualizar o valor da umask, é o umask; é um comando interno do bash 🙂 .

A umask é guardada em nos arquivos profiles; no /etc/profile e arquivo .bash_profile ou .profile que fica no home de cada usuário do sistema. Cada usuário pode ter o seu padrão, para isso, basta alterar o valor no arquivo .bash_profile; caso o arquivo não exista, podemos criar!

Por exemplo, vamos no terminal onde a trinity está logada e vejamos qual o valor da umask dela:

$ umask
0022

Bem, agora a questão é: sei o valor da umask… mas que permissão é essa? Para descobrir, vamos ter que fazer uma continha de padeiro.

Sei que a permissão total no sistema é 777 e o valor da umask é 022. Simplesmente eu subtraio o valor da umask do valor da permissão total:

777 – 022 = 755

Descobrimos então, que a permissão padrão para uma umask de valor 022 é 755!

Agora um detalhe! Quando falamos em permissão total, estamos falando de rwx, que em um diretório, significa:

r – Posso listar o conteúdo
w – Posso criar arquivos
x – Posso entrar no diretório

Já para arquivos, estamos falando que:

r – Posso ler o conteúdo
w – Posso alterar o conteúdo
x – Posso executar esse arquivo

Só que o detalhe é: o sistema por padrão não adota que todo arquivo criado será um executável… então a opção de x, isto é, de execução não vem setada por padrão, senão terei vários arquivos executáveis que na verdade são apenas arquivos de texto.

Assim, no caso da permissão padrão para criação de arquivos, sempre vai ser retirado o x… e temos que fazer a continha de padeiro novamente, para descobrir qual a permissão padrão para criação de arquivos, ja que acima, a permissão padrão é para diretórios!

Vejam a tabela:

Permissao para arquivos

Então, resumindo, subtraímos a permissão x que tem o valor 1, porque o Linux presume que nem todo arquivo criado será executável!

Continuando com as permissões especiais… no post anterior, vimos que tanto o neo como a trinity, já estão criando arquivos dentro do diretório /mnt/private, com o grupo private:

$ cd /mnt/private/

$ ls -l
total 0
-rw-r–r– 1 neo     private 0 2009-03-29 02:43 arquiteto.txt
-rw-r–r– 1 trinity private 0 2009-03-29 02:41 sentinelas.txt

Mas… uma coisa ainda não está certa. Vejam as permissões dos arquivos que o neo e a trinity criaram. Está como 644 (leitura e escrita para os donos, e somente leitura para o grupo e outros).

Se estamos falando de um diretório onde as pessoas que fazem parte do grupo devem conseguir ler e escrever… temos que alterar as permissões. Só que, se alterarmos as permissões na mão, da próxima vez que criar arquivos, ainda assim estarão com as permissões erradas.

Então, nessa hora entra em ação a umask… Como vimos, a trinity tem a umask 022, que é a padrão do sistema.

No caso, precisamos que para os arquivos que forem criados daqui pra frente, os usuários que façam parte do grupo private, tenham permissão de escrita também… e não somente o dono!

Para calcular a nova umask da trinity e do neo, vamos fazer conta de padeiro de novo!

Descobrindo nova umask
Bem, descobrimos que a umask que deve ser usada, é a 002. E, como comentado acima, o sistema não presume que todo arquivo criado é um executável, fazemos a continha de padeiro de novo, para saber qual a permissão padrão para os arquivos:

Novo valor de permissao para arquivos

Agora que ja sabemos o valor das permissões para criação de novos arquivos, vamos corrigir a umask dos usuários trinity e neo no arquivo .bash_profile que está no home dos usuários.

Só lembrando, dependendo da distribuição, o arquivo a ser editado é .profile dentro do diretório home do usuário.

# vim /home/trinity/.bash_profile

Localize a linha referente ao umask:

#umask 022

A linha esta comentada… descomente a linha e vamos alterar o valor da umask. Ficará assim:

umask 002

E, para que a nova umask comece a valer, basta que os usuários desloguem e loguem novamente. Ou então… para facilitar, logados como usuários trinity e neo, basta atualizar o arquivo .bash_profile ou .profile:

$ source ~/.bash_profile

E pra conferir, como usuários trinity e neo, executa o comando abaixo… que já deve sair a umask correta!

$ umask
0002

Agora, como root, vamos analisar os novos arquivos que os usuários neo e trinity criaram dentro do diretório /mnt/private:

# cd /mnt/private/

# ls -l
-rw-rw-r– 1 neo     private 0 Mai 16 10:10 zion.txt
-rw-rw-r– 1 trinity private 0 Mai 16 10:10 report.txt

Bem, a trinity criou um arquivo chamado reports.txt e o neo, um arquivo chamado zion.txt… e agora, esses arquivos já vieram com a permissão correta! No bloquinho de permissões do grupo, quem faz parte do grupo, pode editar os arquivos que eles criaram!

E ficamos aqui por enquanto! No próximo post, irei falar sobre as outras permissões especiais… faltam duas! Até la! 🙂 .