Não, não, não & não:
Vou explicar para uid (é o mesmo para gid) Um processo pode mover ID entre efetivo, real e outro. Um processo também pode definir arbitrariamente um ID se e somente se ele tiver o CAP_SETUID.
Vamos ver a maneira como o UID e o GID são implementados:
Existem dois números armazenados em uma tabela de banco de dados (um arquivo), ambas as tabelas são independentes. Eu tenho um UID e um GID principal. Ambos chamavam Richard, mas com números diferentes. As únicas conexões são: em / etc / passwd, ele lista o nome de usuário, o UID e o GID principal. Em / etc / group, lista groupname, GID, UIDs.
Na maioria das vezes, essas relações não são verificadas, exceto: no login e quando o setgid é chamado (eu acho).
Para eficiência, apenas o que é necessário é verificado.
- Um processo pode mover o ID entre efetivo, real e outro (arquivo, salvo).
- Um processo também pode definir arbitrariamente um ID se e somente se ele tiver o recurso CAP_SETUID.
-
Na página de manual de setreuid() ,
setreuid()sets real and effective user IDs of the calling process.
Fornecer um valor de -1 para o ID do usuário real ou efetivo força o sistema a deixar esse ID inalterado.
Processos não privilegiados só podem definir o ID do usuário efetivo para o ID do usuário real, o ID do usuário efetivo ou o ID do usuário configurado salvo.
Os usuários desprivilegiados só podem definir o ID do usuário real como o ID do usuário real ou o ID do usuário efetivo.
Se o ID do usuário real for definido ou o ID do usuário efetivo for definido com um valor diferente do ID do usuário real anterior, o ID do usuário configurado será configurado para o novo ID de usuário efetivo.
Completamente de forma análoga, setregid () define os IDs reais e efetivos do grupo do processo de chamada, e todos os itens acima são mantidos com "group" em vez de "user".