Saltar para: Posts [1], Pesquisa [2]

SAPO developers blog

SAPO developers blog

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?

Mais sobre mim

Subscrever por e-mail

A subscrição é anónima e gera, no máximo, um e-mail por dia.

Arquivo

  1. 2012
  2. J
  3. F
  4. M
  5. A
  6. M
  7. J
  8. J
  9. A
  10. S
  11. O
  12. N
  13. D
  1. 2011
  2. J
  3. F
  4. M
  5. A
  6. M
  7. J
  8. J
  9. A
  10. S
  11. O
  12. N
  13. D
  1. 2010
  2. J
  3. F
  4. M
  5. A
  6. M
  7. J
  8. J
  9. A
  10. S
  11. O
  12. N
  13. D
  1. 2009
  2. J
  3. F
  4. M
  5. A
  6. M
  7. J
  8. J
  9. A
  10. S
  11. O
  12. N
  13. D