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!

Perdeu algo no sistema? Utilize o find ou o locate!

Neste post, irei abordar os comandos find e locate que são utilizados para fazer buscas no sistema.

Ambos tem a mesma função; porém o comando find executa a busca direto no local que você especificou, enquanto o comando locate executa a busca a partir de uma base.

Explicando melhor… com o comando find, cada vez que solicitamos uma busca, ele tenta localizar o que pedimos dentro do local que especificamos e aproveita checa os subdiretórios também. Assim, uma busca com o find pode demorar um pouco, principalmente se o local especificado tiver muitos diretórios!

A sintaxe do comando find é:

find caminho opções nome_do_que_será_procurado

Exemplo:

# find / -name passwd
/etc/passwd
/etc/pam.d/passwd
/usr/bin/passwd
/usr/share/lintian/overrides/passwd
/usr/share/linda/overrides/passwd
/usr/share/doc/passwd

A leitura do comando acima, seria algo como “procure no diretório / algo que case com o nome (opção -name) passwd”; ou seja, pedimos para o find procurar dentro da estrutura do diretório / algo que tenha passwd no nome!

Outro exemplo de uso do find:

# find /etc/ -type d -name apt
/etc/apt

Acima, pedi para o comando find localizar dentro da estrutura do /etc algum diretório (opção type -d) algo que case com o nome apt!

A opção -type aceita os seguintes argumentos: farquivos; ddiretórios e llinks simbólicos.

Agora, falando sobre o comando locate, ele faz a busca dentro de uma base que é construída com um outro comando, o updateb.

Assim a busca sendo um pouco mais rápida, pois o locate vai usar a base que o updatedb construiu! Só um detalhe muito importante: imagine que você tenha atualizado a base do comando locate e em seguida crie um novo arquivo. Se você não executar o updatedb novamente, o arquivo que acabou de ser criado não será localizado pelo locate!

Então, antes de vermos um exemplo do locate, vamos construir a base que ele irá utilizar:

# updatedb

Esse comando pode demorar um pouquinho para ser terminar e deve ser rodado como root (o usuário administrador da máquina). Enquanto o updatedb estiver rodando, o terminal fica indisponível… quando você receber o prompt de volta, significa que o comando terminou e aí pode passar para o próximo passo, que é executar uma busca com o locate.

Exemplo:

# locate passwd
/etc/pam.d/passwd
/etc/passwd
/etc/passwd-
/lib/security/pam_unix_passwd.so
/usr/bin/gpasswd

Um outro exemplo… imagine que você tenha criado um arquivo no sistema e não lembre onde está guardado. E o pior, não faz nem idéia se criou o arquivo como Marketing.txt ou marketing.txt ou MARKETING.TXT….

Aí complicou… são muitas possibilidades, e você está perdido… então vamos usar a opção -i do locate para localizar o tal arquivo! Essa opção é ignore-case, ou seja, ele vai procurar independente do arquivo estar nomeado em maiúsculo ou não!

Então.. primeiro a gente atualiza a base do locate:

# updatedb

Agora, vamos tentar localizar o arquivo:

# locate -i marketing
/root/MaRkEtIng.tXt

Mmmmm.. que nome hein! Se não existisse a opção -i ia ser difícil advinhar onde estava o arquivo!

Bem, esses são os exemplos deste post.Os comandos find e locate são muito úteis para localizar algo dentro do sistema….

O comando find é poderoso (tem um monte de opções bacanas) e, reza a lenda que ele acha até moeda de um centavo perdida no limbo do seu home 😉 !

Ficam aí duas opções que podemos usar para localizar arquivos e diretórios, mas é importante lembrar que o que foi mostrado aqui não é tudo! Então, para saber mais…

# man find

# find –help

# man locate

# locate –help