TL, DR: você provavelmente deseja /proc/PID/loginuid , mesmo que seu comportamento nem sempre corresponda a logname . Mas não funciona fora da caixa em todas as distribuições. Note que minha resposta assume Linux, não se aplica a outras variantes do Unix.
Eu não acho que você encontrará uma resposta totalmente satisfatória, porque você não tem expectativas claras de que logname faz. Por um lado, você está usando atualmente logname , que é baseado em registros utmp - registros que associam um usuário a um terminal e que são atualizados com a boa vontade do emulador de terminal (muitos não). Por outro lado, você espera que “a possibilidade de alterar o nome de usuário seja limitada ao superusuário”. Este não é o caso dos registros utmp! Como explicado no próprio comentário que você cita , os registros utmp funcionam a maior parte do tempo, mas eles pode ser falsificado.
Definir "o nome de usuário que foi usado para entrar no console" é problemático. Está claro o suficiente em casos nominais, mas há muitos casos complicados. O que acontece se um usuário ligar para su e anexar a sessão de tela de outro usuário? O que acontece se um usuário se conecta à sessão X11 ou VNC de outro usuário? Como você rastreia processos para terminais - o que você faz sobre processos sem terminal de controle?
O Linux na verdade tem um conceito de “login UID”. É visível para cada processo como /proc/PID/loginuid . Esta informação é rastreada pelo kernel, mas cabe ao userland informar ao kernel quando um login ocorre. Isso normalmente é feito por meio de pam_loginuid . Sob o capô, é feito escrevendo para /proc/self/loginuid . O login do Linux O UID segue a ancestralidade do processo, que nem sempre é a definição correta, mas tem o benefício de ser simples.
Tenha em atenção que, se o UID de início de sessão de um processo for 4294967295, o processo poderá alterá-lo. A inicialização começa com o logon UID 4294967295 (igual a -1 como um valor de 32 bits); isso normalmente indica um processo que não faz parte de nenhuma sessão de login . Contanto que o processo de login defina o UID de login corretamente (pouco antes de definir o UID real da raiz para o usuário que está efetuando login), tudo bem. Mas se houver uma maneira de efetuar login sem o UID de login definido, o usuário poderá declarar qualquer UID de login de sua escolha. Portanto, essa informação é confiável somente se todas as maneiras de executar um processo no sistema passarem por uma etapa de configuração do UID de login - esqueça uma e a informação se torne inútil.
Experimentalmente, em uma máquina jessie do Debian, todos os meus processos de execução longa, cujo UID de login é -1, são serviços do sistema. Mas existem maneiras de executar um processo com o login UID de -1, por exemplo, via incron. Não sei quantas outras formas existem; Incron foi o primeiro que eu tentei e funcionou. Na máquina Ubuntu 16.04, a entrada pam_loginuid para lightdm está comentada, não investiguei por quê. Talvez o lightdm e o incron do Ubuntu devam ser considerados bugs de segurança, mas o fato é que hoje você não pode contar com o UID de login funcionando em grandes distribuições.
Veja também Loginuid, should ser permitido alterar ou não (mutável ou não)? , que é sobre uma opção de kernel para impedir que o root altere o UID de login. Mas tenha em atenção que só é eficaz depois de o UID de início de sessão ter sido definido com um valor adequado; Se um usuário conseguir executar um processo com o UID de login ainda definido como -1, ele poderá defini-lo como quiser. De fato, seria mais seguro fazer o init mudar para um valor diferente, digamos -2, e ter pam_loginuid sobrepondo esse valor; então -1 nunca aconteceria e -2 indicaria "desconhecido".