Le mode d'autorisation exécutable S est-il utilisé pour quoi que ce soit ?

Si vous ajoutez le bit setuid pour l'autorisation d'un fichier où vous avez l'autorisation d'exécution, cela change le x à un s pour signifier que si vous exécutez ce fichier, il s'exécutera en tant que propriétaire du fichier plutôt qu'en tant que personne l'exécutant réellement.

Mais j'ai aussi remarqué que si vous ajoutez des s autorisation mais supprimez x permission qu'il change en S dans la liste des autorisations. D'une manière ou d'une autre, cela impliquerait qu'il ne pourrait pas être exécuté, mais qu'il serait simultanément exécuté en tant que propriétaire s'il pouvait être exécuté ? C'est bien ça ?

Ai-je mal compris cette autorisation ? A quoi cela sert? Qu'est-ce que cela signifie ?

Réponse acceptée :

Les quatre combinaisons existent et sont significatives.

"Le véritable propriétaire de ce fichier peut-il l'exécuter ?" et "Qui le système prétendra-t-il exécuter ce fichier ?" sont deux questions distinctes. Les quatre combinaisons sont possibles et significatives.

Chaînes d'autorisations affichées par ls -l ou stat -c %A show, dans la position d'exécution du propriétaire (c'est-à-dire à la place de ? dans ---?------ ), quatre caractères différents, un pour chaque combinaison :

- signifie que le propriétaire ne peut pas exécuter le fichier et, si un non-propriétaire l'exécute, il s'exécute comme cet autre utilisateur .
x signifie que le propriétaire peut exécuter le fichier et, si un non-propriétaire l'exécute, il s'exécute comme cet autre utilisateur .
S signifie que le propriétaire ne peut pas exécuter le fichier et, si un non-propriétaire l'exécute, il s'exécute en tant que propriétaire à la place .
s signifie que le propriétaire peut exécuter le fichier et, si un non-propriétaire l'exécute, il s'exécute en tant que propriétaire à la place .

Le bit setuid et les bits d'exécution sont des bits séparés, et le mode string est vraiment juste un moyen pratique de visualiser les bits d'autorisation, y compris ceux-ci. Une autre façon d'y penser est :

x ou s signifie que le bit d'exécution est défini. - ou S signifie que ce n'est pas le cas.
s ou S signifie que le bit setuid est activé. - ou x signifie que ce n'est pas le cas.

De même, un groupe peut avoir ou non des autorisations d'exécution sur un fichier et, s'il est exécuté, il peut ou non être exécuté avec une identité de groupe différente de celle de l'utilisateur qui l'exécute. Pour qu'un fichier s'exécute avec l'identité de groupe de son propriétaire de groupe plutôt que celle de l'utilisateur qui l'exécute, vous devez définir le bit setgid (------s--- ou ------S--- ).

S ne représente pas un bit de mode séparé. C'est simplement une façon de signifier que le bit setuid (ou setgid) est défini mais que le bit exécutable correspondant n'est pas défini.

$ touch foo
$ chmod u+S foo
chmod: invalid mode: ‘u+S’
Try 'chmod --help' for more information.

Vous pouvez examiner les bits eux-mêmes.

Pour voir que ce sont des bits séparés, utilisez le %a spécificateur de format pour stat au lieu de %A . Pour simplifier les choses, j'ai désactivé tous les autres bits de mode.

$ touch a b c d
$ chmod u=,g=,o= a
$ chmod u=x,g=,o= b
$ chmod u=s,g=,o= c
$ chmod u=xs,g=,o= d
$ stat -c '%A %n' a b c d
---------- a
---x------ b
---S------ c
---s------ d
$ stat -c '%04a %n' a b c d
0000 a
0100 b
4000 c
4100 d

Cela rend clair… si vous êtes à l'aise avec l'octal. Si vous voulez le voir en binaire (ils sont bits après tout), vous pouvez convertir les représentations :

$ stat -c '%a %n' a b c d | perl -pe 's/\d+/sprintf("%012b", oct($&))/e'
000000000000 a
000001000000 b
100000000000 c
100001000000 d

Setuid définit l'ID utilisateur effectif, pas l'ID utilisateur réel.

Les bits d'exécution contrôlent si une tentative d'exécution d'un fichier peut réussir ou non, tandis que les bits setuid/setgid contrôlent l'identité sous laquelle le nouveau processus s'exécute s'il est autorisé à être créé. Il n'y a donc rien d'incohérent ou de surprenant dans la combinaison des permissions S représente (-x,+s ). Ce serait le cas même si un exécutable s'exécutant en tant que propriétaire parce que son propriétaire l'exécutait réellement fonctionnait exactement de la même manière qu'un exécutable s'exécutant en tant que propriétaire parce que quelqu'un l'exécutait mais qu'il était setuid. Mais ce n'est pas comme ça que ça marche.

Le noyau utilise plusieurs numéros pour garder une trace de l'identité de l'utilisateur d'un processus en cours d'exécution. L'un de ces numéros est l'UID, et un autre est l'EUID. Voir cet article pour plus de détails. Le bit setuid entraîne la modification de l'EUID (ID utilisateur effectif), mais l'UID (ID utilisateur réel) reste le même. Une utilisation de cela pour permettre l'échange de signaux entre des processus qui partagent un UID mais qui ont des EUID différents, mais une autre est qu'il permet à un programme conçu pour avoir son bit setuid de vérifier qui l'a exécuté .

Par exemple, passwd doit être setuid, car seul root peut modifier les entrées dans la base de données de mots de passe :

$ ls -l "$(command -v passwd)"
-rwsr-xr-x 1 root root 54256 May 16 19:37 /usr/bin/passwd

-rwsr-xr-x a r-x à la fin, pour les autres . En raison du x , même les utilisateurs qui ne sont pas root ou dans le groupe root peuvent exécuter passwd . Et il a rws près du début, pour le propriétaire . En raison des s , le programme s'exécute en tant que root, même lorsque des non-propriétaires l'exécutent. Mais lorsque vous exécutez passwd vous-même, il réinitialise votre mot de passe, pas celui de root.

passwd est capable d'apporter quelque modification que ce soit à la base de données des utilisateurs et des mots de passe, car elle s'exécute avec l'ID utilisateur effectif de root. Mais il est conçu pour refuser de changer le mot de passe de quiconque sauf l'utilisateur qui l'a exécuté, sauf lorsque cet utilisateur est root, car il vérifie son véritable ID utilisateur.

Connexe :gdomap et à quoi sert-il ?

C'est le cas typique d'utilisation de l'exécutable setuid :créer une interface permettant à un utilisateur de faire exécuter des actions à un autre, de manière limitée et vérifiée par le code de l'exécutable setuid. Il n'est donc sûr que de définir le bit setuid (ou le bit setgid) sur un programme qui est conçu pour avoir ces autorisations.

C'est l'autre pièce du puzzle pour comprendre pourquoi les permissions S signifie n'est pas une énigme :le pouvoir que le bit setuid confère n'a pas obtenir la même chose que d'exécuter réellement le programme en tant que propriétaire , même une fois que le programme a été autorisé à s'exécuter.

Vérification de l'UID et de l'EUID avec une copie de `id` montre comment setuid fonctionne.

D'accord, eh bien, je vais définir le bit setuid sur un exécutable qui n'est pas conçu pour cela, pour montrer comment les ID utilisateur réels et effectifs sont affectés.

L'exécutable sera une copie de l'id programme qui, entre autres, rapporte ses identifiants d'utilisateur réels et effectifs. Bien que ce programme ne soit pas conçu pour être sétuide, il n'est pas non plus conçu pour changer quoi que ce soit - sauf en produisant une sortie - donc c'est raisonnablement sûr. Mais vous devriez toujours le supprimer par la suite. (Votre copie. Pas l'original.)
Nous utilisons une copie, pas modification des autorisations sur l'original. Vous ne faites pas besoin d'utiliser sudo ou effectuer n'importe quelle action en tant que root pour cela.
Pour l'exécuter en tant qu'autre utilisateur, vous avez besoin d'un deuxième compte utilisateur, mais vous pouvez utiliser su pour effectuer des actions comme cela utilisateur. (Par défaut, la root compte ne vous permet pas de vous connecter avec un mot de passe, donc si vous faites une erreur et exécutez su sans donner le nom d'utilisateur vers lequel vous souhaitez basculer, vous ne deviendrez pas accidentellement root à la place, à moins que vous n'ayez également activé les connexions root. Si vous voulez vraiment utiliser sudo -u user au lieu de su user -c , cependant, alors vous pouvez.)

Mon compte d'utilisateur principal s'appelle ek et mon deuxième compte est ek2 . C'est bien si les vôtres sont différents. D'abord, comme ek , je copie id dans le répertoire courant (qui se trouve quelque part dans mon répertoire personnel) :

$ type -a id
id is /usr/bin/id
$ cp /usr/bin/id .

La copie appartient à l'utilisateur non root qui l'a copiée, mais les autorisations d'origine :

$ ls -l id /usr/bin/id
-rwxr-xr-x 1 ek   ek   39760 Oct  5 11:23 id
-rwxr-xr-x 1 root root 39760 Mar  2  2017 /usr/bin/id

Passer -n à id affiche les noms au lieu des numéros d'identification, -u affiche l'utilisateur (et non d'autres informations comme les groupes), et -r provoque l'affichage de l'ID utilisateur réel. Sans -r , -u affiche l'ID utilisateur effectif. Ce comportement s'applique entièrement à la copie de id Je viens de faire.

Lorsque je l'exécute en tant qu'utilisateur de remplacement, les ID utilisateur réels et effectifs sont tous deux modifiés. Cela fait partie de la façon dont su et sudo sont écrits, et ne sont pas simplement le résultat de su lui-même étant une racine setuid, bien qu'il en soit ainsi. (C'est pourquoi j'ai utilisé passwd comme exemple d'un exécutable setuid typique, plutôt que su ou sudo .) Ceci est notre ligne de base, pour voir que id dans le répertoire courant fonctionne comme prévu :

$ ./id -nu                # ek runs id, displaying the effective user
ek
$ ./id -nur               # ek runs id, displaying the real user
ek
$ su ek2 -c './id -nu'    # ek2 runs id, displaying the effective user
Password:
ek2
$ su ek2 -c './id -nur'   # ek2 runs id, displaying the real user
Password:
ek2

Maintenant, je fais cette copie locale de id setuid :

$ chmod u+s id
$ ls -l id
-rwsr-xr-x 1 ek ek 39760 Oct  5 11:42 id

Maintenant, quand je l'exécute, son véritable ID utilisateur est toujours celui de l'utilisateur qui l'a exécuté, tandis que son ID utilisateur effectif est celui de ek même quand ek2 l'exécute :

$ ./id -nu                # ek runs id, displaying the effective user
ek
$ ./id -nur               # ek runs id, displaying the real user
ek
$ su ek2 -c './id -nu'    # ek2 runs id, displaying the effective user
Password:
ek
$ su ek2 -c './id -nur'   # ek2 runs id, displaying the real user
Password:
ek2

Maintenant, je retire les autorisations exécutables au propriétaire, mais je les laisse pour tout le monde :

$ chmod u-x id
$ ls -l id
-rwSr-xr-x 1 ek ek 39760 Oct  5 11:42 id

ek2 peut toujours l'exécuter comme avec ek l'ID utilisateur effectif, même si ek ne peut pas l'exécuter :

$ ./id -nu                # ek runs id, displaying the effective user
-bash: ./id: Permission denied
$ ./id -nur               # ek runs id, displaying the real user
-bash: ./id: Permission denied
$ su ek2 -c './id -nu'    # ek2 runs id, displaying the effective user
Password:
ek
$ su ek2 -c './id -nur'   # ek2 runs id, displaying the real user
Password:
ek2

Mais, comme indiqué, cela n'a pas produit le même résultat que ek l'exécutant réellement. ek2 ne peut pas vraiment faire ce que ek pourrait faire si ek ont été autorisés à exécuter le programme, à moins que le programme ne le permette.

En relation :Impossible de démarrer Ubuntu sur Acer Aspire ES17 ?