chmod -x chmod
Agosto 02, 2010
jac
Em Fevereiro tornamos público um problema que foi usado nas entrevistas no SAPO durante 2009.
O problema, orientado a candidatos com um background forte em ambientes Linux/UNIX, consistia no seguinte:
"Encontras-te sozinho num Data Center e tens que resolver este problema sem recurso a meios exteriores (nada de telemóvel, nada de internet; o objectivo é resolveres tu o problema). Tens um servidor que não pode ir abaixo. Nessa máquina, alguém teve a brilhante ideia de executar um `chmod -x chmod`. Resolve o problema."
O primeiro ponto a apontar é o objectivo deste problema.
O objectivo não é avaliar se o candidato consegue resolver a situação, mas sim a sua reacção. O ideal seria um misto de excitação, pânico e um olho a saltar fora.
A pergunta serve, no entanto, para avaliar o conhecimento que a pessoa tem sobre estes sistemas e a capacidade de improviso/imaginação.
Durante alguns meses, a cada 3 entrevistas em que usávamos este problema, surgia uma resposta nova.
Hoje vamos abordar algumas delas.
Começamos por soluções que não se aplicam às circunstâncias descritas, como tirar o disco e levá-lo a outra máquina que ainda tenha o chmod operacional.
De seguida, partimos para outras soluções curtas e viáveis:
- usar o perl da máquina, que não usa o chmod ao qual retiramos as permissões
perl -e 'chmod 0755, "chmod"'
- usar o python da máquina, que também não usa o chmod ao qual retiramos as permissões
python -c "import os;os.chmod('testing', 0777)"
- usar o cc para criar um pequeno programa em C que altere as permissões do executável (de forma a que quando compilado tem permissões de escrita)
- lançar a BusyBox, que tem um chmod lá dentro
Algumas soluções semelhantes mas com ligeiras nuances:
- copiar um outro executável para um novo, que fica com as permissões correctas, e copiar o conteúdo do chmod para lá
- usar o cc para criar um outro executável, com permissões de execução, e de seguida copiar o conteúdo do chmod para lá
cat /bin/chmod > new_executable
- fazer um tar do ficheiro e editar o tar para alterar as permissões lá dentro
- fazer um tar do ficheiro alterando as permissões dos ficheiros ao adicioná-los
- usar o tar para criar um arquivo com as permissões correctas e descompactá-lo on-the-fly:
tar --mode 555 -cvf - chmod | tar xvf -
- fazer algo semelhante com o cpio
echo chmod | cpio -o | perl -pe 's/^(.{21}).../${1}755/' | cpio -i -u
Depois começam a surgir soluções que são dependentes da distribuição:
- em Debian, ver se o pacote ainda está em cache
- em Red Hat, usando o yum, ir ver se o RPM ainda está na máquina
E há mais (getfacl, setfacl, chflags, etc.), cada uma mais inovadora que a anterior (como um `alias chmod='/lib/ld-2.11.1.so /bin/chmod`, ou o exemplo mais abaixo).
Convém neste ponto explicar o que se sucede quando se coloca uma questão destas numa entrevista.
A interacção em torno deste problema não se cinge a uma pergunta e uma resposta, mas sim à exploração do conhecimento e capacidade inventiva da pessoa.
Eis um exemplo baseado numa entrevista verídica:
Candidato - Tenho perl na máquina?
Entrevistador - Tens.
C - Então uso o chmod do perl, que é built-in!
E - Certo. Agora vou-te tirar o perl da máquina.
C - Hum... Tenho cc?
E - Tens.
C - Então posso fazer um programa em C que usa a system call do chmod para alterar as permissões ao chmod.
E - Certo. Agora vou-te tirar o compilador.
C - Hum... Disseste que não tenho acesso à net, mas não disseste nada sobre os outros servidores no Data Center. Abro um socket para outro servidor, faço um tar do chmod de lá preservando as permissões, trago-o para a máquina a faço untar.
E - Certo. Agora vou-te tirar as outras máquinas do Data Center.
C - OK... Bem, posso sempre lançar a BusyBox, que deve estar na máquina e que tem o chmod lá dentro!
E - OK, mas agora vamos-te tirar a BusyBox. Consegues arranjar outra maneira de resolver o problema?
[o candidato pensa um pouco, olha para cima e fala como se estivesse a falar consigo próprio]
C - Eia... Esta é mesmo rabuscada... Faço um attrib ou um ls extendido para forçar o inode para a cache; agora só tenho que editar o inode que está em cache sem que o kernel se aperceba, e posso usar o sed para isso, desde que seja root; vou ao kcore procurar as estruturas do VFS e altero-lhe o bit de execução; vou é ter que ler documentação; depois é só usar o chmod para lhe repor as permissões.
[breve pausa para recuperarmos]
(já agora, e a título informativo, o candidato do texto acima encontra-se hoje em dia a trabalhar no SAPO)
Para além de todas estas (e outras) soluções (e tentativas de solução) que nos foram aparecendo, surgiram também alguns comentários interessantes como:
- Resolver o problema? Qual problema? A máquina continua a funcionar!
E questões como:
- Mas porque raio é que a bin de um servidor estava writable?