J'utilise un système de bureau Ubuntu 12.04. Jusqu'à présent, je n'ai installé que quelques programmes (j'ai des droits sudo).

1. Lorsque je vérifie la liste des utilisateurs du système, je vois une longue liste, comme plus de 20 utilisateurs - quand ces utilisateurs ont-ils été créés (par exemple, démon, sys, synchronisation, jeux, pouls, etc.)? Comment sont-ils liés aux nouveaux programmes installés?

2. Si j'exécute un programme sur mon système, il devrait s'exécuter avec mon UID. Mais en faisant un ps , je vois de nombreux autres programmes fonctionnant avec différents UID (comme root, daemon, avahi, syslog, colord, etc.) - comment ces programmes ont-ils démarré avec différents UID?

Les comptes d'utilisateurs sont utilisés non seulement pour les utilisateurs humains réels, mais également pour exécuter les services système et parfois en tant que propriétaires de fichiers système. Cela est dû au fait que la séparation entre les ressources des utilisateurs humains (processus, fichiers, etc.) et la séparation entre les ressources des services système nécessitent les mêmes mécanismes sous le capot.

Les programmes que vous exécutez s'exécutent normalement avec votre ID utilisateur. Seuls les démons système s'exécutent sous leur propre compte. Soit le fichier de configuration qui indique quand exécuter le démon indique également quel utilisateur doit l'exécuter, soit le démon passe à un compte non privilégié après le démarrage. Certains démons nécessitent des privilèges administratifs complets, ils s'exécutent donc sous le compte root . De nombreux démons n'ont besoin d'accéder qu'à un périphérique matériel spécifique ou à des fichiers spécifiques, ils s'exécutent donc sous un compte utilisateur dédié. Cela est fait pour la sécurité: de cette façon, même s'il y a un bogue ou une mauvaise configuration dans l'un de ces services, cela ne peut pas conduire à une attaque complète du système, car l'attaquant sera limité à ce que ce service peut faire et ne sera pas capable d'écraser des fichiers, d'espionner des processus, etc.

Sous Ubuntu, les ID utilisateur compris entre 0 et 99 sont créés lors de l'installation du système. 0 est root; la plupart de celles comprises entre 1 et 99 n'existent que pour des raisons historiques et ne sont conservées qu'à des fins de compatibilité avec certaines installations locales qui les utilisent (quelques entrées supplémentaires ne font pas de mal). Les ID utilisateur compris entre 100 et 999 sont créés et supprimés dynamiquement lorsque des services nécessitant un ID utilisateur dédié sont installés ou supprimés. La plage à partir de 1000 est réservée aux utilisateurs humains ou à tout autre compte créé par l'administrateur système. Il en va de même pour les groupes.

Je suppose que vous trouvez cette liste d'utilisateurs en vérifiant /etc/passwd? C'est tout à fait normal - les `` utilisateurs '' servent à transporter un ensemble d'autorisations, utiles pour verrouiller non seulement les `` utilisateurs réels '' mais aussi des programmes dans certaines zones de votre système et suivre ce qu'ils ont changé (même concept avec les groupes).

J'ai inséré un de mes /etc/passwdfichiers Raspberry Pi ci-dessous pour référence; vous remarquerez l'utilisateur ntopau bas de ce fichier, créé par le programme ntop(surveillance du réseau). De même sshd, gnatsles rapports de bogues, etc.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
pi:x:1000:1000:,,,:/home/pi:/bin/bash
sshd:x:101:65534::/var/run/sshd:/usr/sbin/nologin
ntp:x:102:104::/home/ntp:/bin/false
statd:x:103:65534::/var/lib/nfs:/bin/false
messagebus:x:104:106::/var/run/dbus:/bin/false
usbmux:x:105:46:usbmux daemon,,,:/home/usbmux:/bin/false
lightdm:x:106:109:Light Display Manager:/var/lib/lightdm:/bin/false
smmta:x:107:110:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:108:111:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
Debian-exim:x:109:113::/var/spool/exim4:/bin/false
ntop:x:110:115::/var/lib/ntop:/bin/false

Quand ces utilisateurs ont-ils été créés?

Dans le cas de ceux que vous avez mentionnés, ils ont été créés lors de l'installation du système. Ces comptes d'utilisateurs sont classiques, certains remontant à des décennies. Ils sont également standardisés. La base standard Linux les divise en:

• le besoin des comptes utilisateur standard, root, binet daemon; et
• l' option des comptes utilisateur standard adm, lp, sync, shutdown, halt, mail, news, uucp, operator, manetnobody

D' autres comptes d'utilisateurs qui sont mentionnés ici - pulse, avahi, colordet Debian-exim(choisir un à partir du fichier de mot de passe py4on) - nous amener à la question suivante.

Comment sont-ils liés aux nouveaux programmes installés?

Les comptes d'utilisateurs non standard sont créés et détruits par les «scripts de maintenance» pour divers packages, au fur et à mesure que ces packages sont installés et purgés. Un compte d'utilisateur sera créé par le soi-disant postinstscript de maintenance du package , qui s'exécute getentpour voir si le compte d'utilisateur existe déjà et useradds'il ne l'est pas. En théorie, il serait supprimé par le soi-disant postrmscript de maintenance du package , en cours d'exécution userdel.

En pratique, les comptes d'utilisateurs des packages ne sont pas supprimés. Le wiki Fedora (qv) explique que cela serait très difficile. Voir le bogue Debian # 646175 pour un exemple de cette justification en action, où il est simplement décidé de ne pas supprimer le rabbitmqcompte utilisateur lorsque le paquet est purgé, pour résoudre un problème avec un démon qui continue de fonctionner sous l'égide de ce compte.

Comment ces programmes ont-ils démarré avec différents UID?

Sous Unix et Linux, un processus exécuté sous l'égide du superutilisateur peut changer son compte d'utilisateur en quelque chose d'autre et continuer à exécuter le même programme, mais l'inverse n'est pas autorisé. (Il faut utiliser le mécanisme set-UID.)

Le système de gestion dæmon fonctionne en tant que superutilisateur. Ses données de configuration spécifient que des démons particuliers s'exécutent sous l'égide de comptes d'utilisateurs particuliers:

• Avec System 5, rcle script /etc/init.dutilise un outil d'aide tel que start-stop-daemonet son --chuidoption.
• Avec un gestionnaire de services de famille daemontools, les runappels de script setuidgid, s6-setuidgid, chpstou runuidavec le nom du compte utilisateur. Il existe des exemples de cela dans /unix//a/179798/5132 qui définissent le nagioscompte d'utilisateur.
• Avec upstart, il y a une setuidstrophe dans un fichier de travail, qui spécifie le compte utilisateur. Ce n'est pas particulièrement fin, et parfois on veut ce qui est décrit sur /superuser//a/723333/38062 .
• Avec systemd, il y a un User=paramètre dans le fichier d'unité de service, qui spécifie le compte d'utilisateur.

Lorsque le système de gestion dæmon génère un processus pour être le dæmon, ces mécanismes abandonnent les privilèges de superutilisateur afin que le processus dæmon continue de s'exécuter sous l'égide du compte d'utilisateur non privilégié.

Il y a une explication assez longue pour laquelle une bonne gestion des démons se fait de cette façon. Mais vous n'avez pas demandé pourquoi; seulement quand, comment et d'où. ☺ Un très bref précis donc:

Les systèmes d'exploitation Unix et Linux isolent les processus s'exécutant sous l'égide de différents comptes d'utilisateurs les uns des autres. Historiquement, si l'on était en mesure de reprendre un démon qui fonctionnait en tant que superutilisateur, on pouvait faire tout ce qu'on voulait. Un démon qui s'exécute sous l'égide d'un compte non privilégié, d'autre part, ne peut accéder qu'aux fichiers, répertoires, périphériques et processus que ce compte non privilégié peut. Un système de programmes Dæmon sans confiance mutuelle fonctionnant tous sous l'égide de différents comptes d'utilisateurs et incapables d'accéder / de contrôler les fichiers / répertoires / processus / périphériques (internes, approuvés) les uns des autres, est donc beaucoup plus difficile à déchiffrer.

Lectures complémentaires

• Jonathan de Boyne Pollard (2014). Un regard côte à côte sur les scripts d'exécution et les unités de service. . Réponses fréquemment données.
• Gestion des comptes dans les scripts du responsable . Wiki Debian.
• Emballage: UsersAndGroups . Wiki du projet Fedora.
• "Chapitre 15. Utilisateurs et groupes" . Spécification de base standard Linux 2.1 . 2004. Free Standards Group.
• "9.2 Utilisateurs et groupes" . Manuel de politique de Debian . 2014-11-22. La liste de diffusion de la politique Debian.
• "37.3. Utilisateurs standard" . Guide de déploiement RHEL . 11e édition. 2013. Red Hat.
• Utilisateurs et groupes . Arch wiki.
• Carol Hurwitz et Scott McPeak (2001-02-12). Abolissez les démons racines! . DOI 10.1.1.120.3567 .

Sous Linux, lorsque nous installons un service, il crée un utilisateur de son nom de service ou similaire à celui-ci afin qu'il ne puisse pas accéder aux autres fichiers.