Chaque processus dans un système de type UNIX, comme tous les fichiers, a un propriétaire (l'utilisateur, qu'il soit réel ou un système de « pseudo-utilisateur », tels que daemon
, bin
, man
, etc.) et un propriétaire du groupe. Le propriétaire du groupe pour les fichiers d'un utilisateur est généralement le groupe principal de cet utilisateur et, de la même manière, tous les processus que vous démarrez appartiennent généralement à votre ID utilisateur et à votre ID de groupe principal.
Parfois, cependant, il est nécessaire d'avoir des privilèges élevés pour exécuter certaines commandes, mais il n'est pas souhaitable de donner des droits administratifs complets. Par exemple, la passwd
commande doit avoir accès au fichier de mots de passe cachés du système pour pouvoir mettre à jour votre mot de passe. Évidemment, vous ne voulez pas donner à chaque utilisateur des privilèges root, juste pour qu'ils puissent réinitialiser leur mot de passe - cela conduirait sans aucun doute au chaos! Au lieu de cela, il doit y avoir un autre moyen d'accorder temporairement des privilèges élevés aux utilisateurs pour effectuer certaines tâches. C'est à cela que servent les bits SETUID et SETGID. C'est un moyen de dire au noyau d'augmenter temporairement les privilèges de l'utilisateur, pendant la durée de l'exécution de la commande marquée. Un binaire SETUID sera exécuté avec les privilèges du propriétaire du fichier exécutable (généralementroot
), et un binaire SETGID sera exécuté avec les privilèges de groupe du propriétaire du groupe du fichier exécutable. Dans le cas de la passwd
commande, qui appartient à root
et est SETUID, elle permet aux utilisateurs normaux d'affecter directement le contenu du fichier de mot de passe, de manière contrôlée et prévisible, en s'exécutant avec les privilèges root. Il existe de nombreuses autres SETUID
commandes sur UNIX comme les systèmes ( chsh
, screen
, ping
, su
, etc.), qui tous exigent des privilèges élevés pour fonctionner correctement. Il existe également quelques SETGID
programmes, où le noyau modifie temporairement le GID du processus, pour permettre l'accès aux fichiers journaux, etc. sendmail
est un tel utilitaire.
Le sticky bit
sert un but légèrement différent. Son utilisation la plus courante consiste à s'assurer que seul le compte d'utilisateur qui a créé un fichier peut le supprimer. Pensez au /tmp
répertoire. Il a des autorisations très libérales, qui permettent à n'importe qui de créer des fichiers là-bas. Ce qui est bon et permet aux processus des utilisateurs de créer des fichiers temporaires ( screen
, ssh
, etc, conserver les informations d'état /tmp
). Pour protéger les fichiers temporaires d'un utilisateur, /tmp
le bit collant est défini, de sorte que moi seul puisse supprimer mes fichiers et que vous seul puissiez supprimer le vôtre. Bien sûr, root peut tout faire, mais nous devons espérer que le sysadmin n'est pas dérangé!
Pour les fichiers normaux (c'est-à-dire pour les fichiers non exécutables), il est inutile de définir les bits SETUID / SETGID. SETGID sur les répertoires de certains systèmes contrôle le propriétaire du groupe par défaut pour les nouveaux fichiers créés dans ce répertoire.
Je pense que vous voulez dire le bit "SGID" d'un fichier, qui n'est pas le même que son GID.
Voici un fichier typique sur mon ordinateur (sortie de ls -l):
Si vous regardez les 10 premiers symboles,
(a) -: Il s'agit simplement d'un ancien fichier (par opposition à un répertoire, un lien symbolique, un tuyau, etc. ...)
(b) rw-: Le propriétaire peut lire et écrire ce fichier, mais pas l'exécuter. Le propriétaire est "bristol" comme vous pouvez le voir plus loin dans la ligne.
(c) r--: les membres du groupe auquel appartient ce fichier ("utilisateurs" dans l'exemple) autres que le propriétaire peuvent lire, mais pas écrire ou exécuter ce fichier.
(d) ---: Personne d'autre ne peut accéder à ce fichier (sauf root bien sûr).
Le champ GID est celui qui vous indique à quel groupe ce fichier appartient - dans ce cas "utilisateurs".
Le champ que vous vouliez probablement, sur la base de votre description, est le bit SGID, et voici une meilleure explication que je ne pourrais trouver:
http://www.codecoffee.com/tipsforlinux/articles/028.html
La version courte est: si un fichier exécutable a le bit SGID défini, alors toute personne qui ne fait pas partie du groupe mais qui peut exécuter ce fichier obtient temporairement les droits de ce groupe pendant l'exécution du programme.
Par exemple, si vous avez un groupe "spool" qui peut lire et écrire des fichiers dans le répertoire du spouleur d'impression, vous ne voulez pas que n'importe qui puisse jouer avec ce répertoire mais vous voulez qu'ils puissent imprimer des fichiers, vous pouvez faire certains programmes ou scripts d'impression ont le groupe "spool" et définissent le bit SGID et lorsque quelqu'un lance ce programme, le programme peut désormais écrire dans le répertoire du spouleur sans que la personne qui l'exécute n'ait un accès complet.
la source
drwxrwxrwt .... 2 sys .... sys .... 1024 Jul 24 15:17 tmp
. Que signifie laabbbcccddt
(lettre 't')? - Je comprends que "d = répertoire", "rwx = lire, écrire, exécuter"; mais je n'ai jamais vu le «t» à la fin auparavant. Est-ce une autorisation spéciale pour le dossier tmp?Le GID est, comme vous l'avez trouvé, le numéro d'identification d'un groupe. C'est simplement un moyen pratique pour le système d'exploitation d'exprimer le groupe (d'utilisateur) associé à quelque chose (un processus, un fichier, etc.); au lieu d'un identificateur de chaîne potentiellement long, il peut être exprimé sous la forme d'un nombre de taille fixe.
Dans une valeur d'autorisations de fichier de quatre chiffres octaux (par exemple, 0755), le troisième chiffre spécifie les autorisations du groupe sur le fichier. Si vous omettez le premier chiffre, c'est le deuxième chiffre qui spécifie les autorisations du groupe. Notez que les fichiers et répertoires sont traités de la même manière à cet égard, mais que la signification exacte de chaque bit d'autorisations est quelque peu non intuitive dans le cas des répertoires.
Les deux concepts sont liés, mais servent à des fins très différentes.
Quant à votre question "est-il même important de définir ces autorisations?"; ils sont toujours définis sur quelque chose , mais comme dans la plupart des cas, le chiffre initial est 0 ("rien de spécial"), il a tendance à être omis par souci de concision. La nécessité de spécifier une autre valeur dépend entièrement du modèle d'utilisation du fichier ou du répertoire en question.
la source