What is the error I get with
login
?
Ao pesquisar pelo código-fonte de login
, vemos esta passagem:
amroot = (getuid () == 0);
[...]
utent = get_current_utmp ();
/*
* Be picky if run by normal users (possible if installed setuid
* root), but not if run by root. This way it still allows logins
* even if your getty is broken, or if something corrupts utmp,
* but users must "exec login" which will use the existing utmp
* entry (will not overwrite remote hostname). --marekm
*/
if (!amroot && (NULL == utent)) {
(void) puts (_("No utmp entry. You must exec \"login\" from the lowest level \"sh\""));
exit (1);
}
A parte interessting é a cláusula if no final. A mensagem de erro aparece quando getuid()
não é 0 e se não houver entrada de entrada. getuid()
retorna o ID do usuário real do processo de chamada. Se você invocar login
com o setuid flag set, o uid real e o uid efetivo são diferentes. login
é, como o comentário no snippet de origem sugere, "exigente" em tais casos: falha e lança o erro mencionado.
Why does
login
work withsudo
?
sudo
possui o bit setuid set, assim euid e ruid diferem. Mas, o sudo executa o binário de login
e define o uid real e o efetivo para o usuário de destino. Portanto, não falhará mais.
Why my simple script to run
whoami
doesn't work?
Seu script tem uma linha shebang ( #!
) nele (eu suponho). O que acontece é o seguinte: o kernel abre o executável (no seu caso, um arquivo de texto) e observa um #!
. Em vez do arquivo de texto, o interpretador fornecido na linha shebang é chamado (por exemplo, /bin/bash
ou /bin/sh
) com o nome do script como primeiro argumento. A maioria dos sistemas operacionais unix e linux ignora o bit setuid quando configurado em um script, porque é um problema de segurança.
Imagine um script com setuid set. O invasor pode criar um link simbólico para esse script, invocar esse script e, em seguida, alterar o link simbólico para seu script, imediatamente antes do interpretador abrir o script por trás do link simbólico (que é o maligno).