Différence entre propriétaire / racine et RUID / EUID

Je suis relativement nouveau dans les concepts mentionnés dans la question et les lire à partir de différentes sources ne fait que les rendre plus confus. Voici donc ce que j'ai compris jusqu'à présent:

Quand on nous donne des autorisations pour un fichier, ils ressemblent à ceci:

-rwsr-xr-- 1 user1 users 190 Oct 12 14:23 file.bin

Nous supposons qu'un utilisateur user2faisant partie du groupe usersessaie de s'exécuter file.bin. Si le bit setuid n'était pas défini, cela signifierait que le RUID et l'EUID de file.binétaient égaux à l'UID de user2. Mais puisque le bit setuid est défini, cela signifie que le RUID est maintenant égal à l'UID user2, alors que EUID est l'UID du propriétaire du fichier, user1.

Mes questions sont:

Quelle est la différence entre le propriétaire du fichier et root? A rootles mêmes autorisations que le propriétaire? Ou aurions-nous besoin d'une entrée distincte dans la liste des autorisations pour root?
Différence entre RUID et EUID?
- Si je comprends bien, le RUID et l'EUID ne s'appliquent qu'aux processus. Si tel est le cas, pourquoi ont-ils la valeur des identifiants utilisateur?
- Si RUID est l'utilisateur qui crée le processus et EUID est l'utilisateur qui exécute actuellement le processus, la première phrase de la première réponse de cette question n'a aucun sens pour moi.
- Ai-je bien compris ce que fait le bit setuid?

— user1956190
source

Voici les réponses:

roota toujours un accès complet aux fichiers et répertoires. Le propriétaire du fichier les possède généralement aussi, mais ce n'est pas toujours vrai. Par exemple:
```
-r-xr----- 1 user1 users 199 Oct 14 18:42 otherfile.bin
```
user1est le propriétaire ; cependant, ils ne peuvent que lire et exécuter , mais ont roottoujours un accès complet ( rwx ) au fichier.
RUID est l' ID utilisateur réel et il ne change jamais (presque). Si vous vous user2connectez au système, le shell est alors lancé avec son véritable ID défini sur user2. Tous les processus qu'ils démarrent à partir du shell hériteront de l'ID réel user2comme de leur ID réel.

EUID est l' ID utilisateur effectif , il change pour les processus (pas pour l'utilisateur) que l'utilisateur exécute et qui ont défini le bit setuid .

S'il user2s'exécute file.bin, le RUID sera user2et l'EUID du processus démarré sera user1.

Prenons le cas de passwd:

-rwsr-xr-x 1 root root 45396 may 25  2012 /usr/bin/passwd

Quand user2veut changer leur mot de passe , ils s'exécutent /usr/bin/passwd.
Le RUID le sera user2mais l'EUID de ce processus le sera root.
user2peut utiliser passwdpour changer uniquement leur propre mot de passe car passwdvérifie en interne le RUID et, si ce n'est pas le cas root, ses actions seront limitées au mot de passe de l'utilisateur réel.
Il est nécessaire que l'EUID devienne rootdans le cas passwdparce que le processus doit écrire sur /etc/passwdet / ou /etc/shadow.

— jcbermu
source

Merci! Maintenant, tout est plus clair. J'ai encore une question. L'EUID ne change que lorsqu'un utilisateur exécute un processus dont le bit setuid est défini? Ou peut-il aussi changer dans une autre situation? Et si oui, quelle est cette situation?

— user1956190

Je pense qu'il n'y a pas d'autre moyen que d'exécuter des processus qui ont le setuidbit défini.

— jcbermu

Un processus qui s'exécute à partir d'un programme «setuid» (c'est-à-dire un processus qui a un UID efficace ≠ UID réel) peut redéfinir l'EUID sur le RUID. Dans certains cas, il peut basculer l'EUID dans les deux sens entre sa valeur initiale (c'est-à-dire le propriétaire du fichier programme) et le RUID. En outre, il peut être en mesure de définir son RUID égal à son EUID. … (Suite)

— Scott

(Suite) ... Les processus privilégiés (ceux avec EUID = 0, alias root) peut définir et RUID à EUID des valeurs arbitraires (par exemple, le login, suet les sudoprogrammes le faire). Généralement, une fois qu'un processus privilégié change ses UID en valeurs non nulles, il n'est plus privilégié et ne peut pas redevenir root. Consultez les pages de manuel setuid (2) , seteuid (2) et setreuid (2) .

— Scott

(Suite)… Il a été introduit comme un hack pour résoudre un problème, qui a ensuite été résolu de manière plus large. Il pourrait avoir été supprimé de Linux, sauf pour le fait qu'un tel élagage briserait les programmes qui l'utilisent. Michael Kerrisk, auteur de The Linux Programming Interface , dit, dans sa version de la page de manuel setfsuid (2) , " setfsuid()est de nos jours inutile et devrait être évité dans les nouvelles applications."

— Scott