O problema é que, de fato, a maneira como o Finder modifica as permissões não afeta apenas os bits indicados, como se poderia pensar. Por algum motivo, ele zera a primeira octal do modo do arquivo e deixa os bits executáveis intocados. Assim, alguns programas vitais obtêm seus setuid/setgid e sticky bits removidos, o que os torna inúteis ou se comportam de maneira irregular.
O bit setuid é necessário para alguns dos programas em /usr/bin/ , porque eles devem interagir com o sistema em um nível inferior aos programas usuais. Por exemplo, sudo , passwd , newgrp ou login precisam de privilégios além daqueles dados a um usuário comum e é por isso que você precisa de uma senha para executá-los. Se você remover seu bit setuid, eles simplesmente não poderão fazer seu trabalho, o que faz com que eles saiam prematuramente ou até quebras.
Assim, por exemplo, as permissões corretas de /usr/bin/login são 4555 ou -r-sr-xr-x e, após a manipulação de seu amigo, temos 0757 ou -rwxr-xrwx . O Terminal.app chama /usr/bin/login para associar seu usuário a um tty (veja man stty ) e o bit setuid ausente faz com que ele falhe. A liberação de um ponteiro não alocado é provavelmente um erro relacionado a isso. No OS X 10.6.8, eu não recebo este erro de ponteiro, mas Terminal.app sai imediatamente após o início e eu encontro uma entrada como login[6647]: pam_open_session(): system error in /var/log/system.log .
Editar. Como Antoine Lecaille menciona em um comentário, uma maneira simples de tornar o Terminal.app disfuncional é emitir $ sudo chmod -s /usr/bin/login . Observe que você não pode nem abrir uma nova janela depois, pois isso também depende de uma chamada para efetuar login. Para desfazer, basta fazer $ sudo chmod +s /usr/bin/login .
Eu testei o efeito do Finder nas permissões da seguinte forma:
$ # create a directory with the same permissions as /usr/bin
$ mkdir -m 755 test
$ sudo chown root:wheel test
$ ls -l | grep test
drwxr-xr-x 2 root wheel 68 Jul 6 15:01 test
$ # create 4096 empty files with all possible permissions
$ cd test
$ sudo touch file_{0..7}{0..7}{0..7}{0..7}
$ for perms in {0..7}{0..7}{0..7}{0..7}; do sudo chmod $perms file_$perms; done
O loop for pode levar um minuto para ser concluído porque chmod é lento. Depois disso, você tem arquivos file_wxyz com permissões wxyz na pasta test . Por exemplo
$ ls -l file_4555
-r-sr-xr-x 1 root wheel 0 Jul 6 15:02 file_4555
Agora podemos fazer o truque do seu amigo e alterar as permissões da pasta e todo o seu conteúdo usando o Finder: $ open . e Cmd + I e fazer o que você explicado em seu post. Decidi conceder permissões de leitura para a roda de grupo e direitos de leitura + gravação para todos.
Agora, vamos ver o que aconteceu com nossos arquivos: o canal a seguir lista o diretório, lê a coluna que contém as permissões, classifica-a e suprime as linhas duplicadas:
$ ls -l | awk '{print $1}' | sort -u
-rw-r--rw-
-rw-r--rwx
-rw-r-xrw-
-rw-r-xrwx
-rwxr--rw-
-rwxr--rwx
-rwxr-xrw-
-rwxr-xrwx
total
$ ls -l file_4555
-rwxr-xrwx 1 root wheel 0 Jul 6 15:02 file_4555
Como você pode ver, os setuid / setgid / sticky bits não estão mais configurados; as permissões de leitura e gravação são as mesmas para todos os arquivos; e as permissões agora só diferem em seus bits de execução (dos quais existem oito combinações possíveis).