A resposta aceita é imprecisa. Minha resposta também pode ser questionavelmente precisa ou difícil de seguir, mas parece valer a pena compartilhá-la. :) Esta opção do kernel determina se alguém pode apenas "ecoar 0 > / proc / self / loginuid" quando o loginuid não está definido e então permanece inalterado, ou se modificações nesse valor requerem uma capacidade específica independente do valor atual. Quando isso é verdade (o que normalmente significa que você é root), loginuid só pode ser modificado se não for definido. A razão pela qual a resposta aceita é imprecisa é que sudo e su são tipicamente suid root. Eles são suid root para permitir que o binário mude para um UID efetivo diferente. Na maioria dos sistemas Linux, o usuário root tem todos os recursos por padrão. Portanto, esses programas também têm a capacidade de alternar o atributo loginuid se isso for falso. Se isso for verdade e o sistema estiver configurado corretamente, loginuid deve ter sido definido no shell de login por ssh / login / whatever, e nada pode alterar o valor.
O atributo loginuid não está definido na inicialização do sistema / dentro do init. Normalmente, ele é definido primeiro pelo módulo pam_loginuid nos serviços de "ponto de entrada". Então, você configura o ssh e o login para definir um valor, já que essas são coisas que permitiriam que alguém se "logasse" - daí loginuid. Você não incluiria o módulo na pilha de sudo, por exemplo, porque esse não é um novo login; que está trocando UIDs após o login. O propósito do loginuid é rastrear um usuário do tempo de login. Você pode usar o daemon de auditoria para registrar processos executados por um usuário específico, mesmo depois de trocarem contas com su ou sudo. O utilitário logname usa esse atributo em sistemas mais novos para identificar o "usuário logado" independentemente dos valores efetivos ou reais (sistemas mais antigos usam o terminal de controle para procurar um evento de login a partir do utmp).
Os processos herdam o atributo loginuid de seu processo pai, BTW.
Portanto, esse parâmetro controla se o atributo loginuid pode ser modificado. Menciona o systemd por causa de como o init funciona. O kernel inicia o init e o init não possui loginuid. Em seguida, o init inicia os serviços e os que não possuem login. Com o init normal do System V, um administrador pode efetuar login e, digamos, executar "/etc/init.d/someservice restart". O atributo loginuid do administrador é definido quando o ssh in é transferido para a raiz. Em seguida, eles executam o script de inicialização, que herda seu loginuid. Se o valor "loginuid immutable" for definido, o script init ou admin não poderá fazer a chamada do sistema, que limpa ou redefine o atributo lognuid antes de iniciar o daemon, e agora o daemon está executando com loginuid do administrador, estragando logs de auditoria , etc. Se o valor for modificável, então há uma chamada de sistema (audit_setloginuid ()) que pode ser feita por um processo com recursos apropriados (talvez / sbin / service, por exemplo) para limpar ou definir um valor razoável para loginuid em o daemon fornecido.
A maneira como o systemd (e o upstart, e talvez alguns outros sistemas init) funcionam, o administrador não executa diretamente os scripts init. Em vez disso, o administrador envia um comando para o processo init e, em seguida, o processo de inicialização faz a ação de reinicialização (ou qualquer outra coisa) por conta própria. Como o init possui um loginuid não configurado, o script init gerado herda esse valor (não definido), e o script init pode definir seu próprio loginuid mesmo que ele possa ter sido executado como um usuário não-root. É indiscutivelmente mais seguro, já que nada precisa de recursos especiais; tudo pode ser feito como um usuário comum.
Então, se você tem um sistema init desacoplado, geralmente não há razão legítima para qualquer coisa não-raiz estar alterando o atributo loginuid, uma vez que é inicialmente definido, e assim pode ser definido essencialmente imutável.
Para responder à pergunta sobre "o que isso lhe dá", bem, não muito. Existem provavelmente programas que concedem acesso com base no loginuid em vez do uid ou euid, mas esses são poucos e distantes entre si. Em geral, o acesso é controlado com base nos contextos do SELinux, EUID, UID ou recursos de processo. Mudar seu loginuid para 0 não deve levar você a nada - e provavelmente deve acionar um sistema de monitoramento projetado para capturar logins raiz remotos. :) Alguns sites usam o auditd para rastrear a execução do processo / chamadas do sistema, e esses sites podem precisar que o loginuid seja preciso para ter regras de auditoria do sistema em funcionamento. Mas se você está fazendo esta pergunta sobre um kernel que você está compilando, você não está operando um desses sites. :)