Pourquoi y a-t-il une entrée man dans / etc / passwd


23

J'ai remarqué qu'il y a une entrée pour l'utilisateur man dans mon /etc/passwdfichier. Quel est le but de cet utilisateur?

man:x:6:12:man:/var/cache/man:/bin/sh

Réponses:


31

man(la commande, pas l'utilisateur) est une application d'aide. Les applications fournissent des pages de manuel dans leurs packages, mais mandoivent savoir où elles se trouvent et quelle aide elles fournissent. Pour accélérer les choses - il mann'est donc pas question de rechercher l'ensemble du système de fichiers lorsque vous tapez man <command>- ces pages de manuel sont indexées dans une base de données par une commande appelée mandb.

Dans Ubuntu mandbstocke les index dans une base de données GNU gdbm à /var/cache/man/index.db(et quelques versions spécifiques à une langue dans le même répertoire). Il s'agit d'une base de données de hachage de valeur-clé qui n'est pas différente de memcache ou d'une centaine d'autres implémentations sur des idées similaires. C'est binaire, léger et rapide. Je vais vous donner un exemple de la façon de jouer avec à la fin.

Cette indexation est prévue pour s'exécuter quotidiennement dans Ubuntu par /etc/cron.daily/man-db. Le script entier s'exécute en tant que root et fait un peu de nettoyage en premier, mais à la fin, nous voyons qu'il mandbest exécuté en tant manqu'utilisateur:

# --pidfile /dev/null so it always starts; mandb isn't really a daemon,
# but we want to start it like one.
start-stop-daemon --start --pidfile /dev/null \
                  --startas /usr/bin/mandb --oknodo --chuid man \
                  $iosched_idle \
                  -- --no-purge --quiet

Il ne s'agit pas de changer de groupe, c'est pourquoi tous les propriétaires de groupe /var/cache/mansont toujours root.

Mais pourquoi mandbfonctionne-t-il en tant qu'utilisateur différent? Il pourrait (probablement) fonctionner aussi bien rootmais il traite les entrées d'une variété de sources (regardez manpath). L'exécution en tant que son propre utilisateur isole le système du processus qui explose - ou pire - est exploité par des pages de manuel malformées, corrompues ou malveillantes.

Le pire qui pourrait arriver n'affecterait que l' manindex des pages. Boo hoo. Vous pouvez le confirmer avec quelque chose comme:

sudo -u man find / -writable 2>/dev/null

Et vous pouvez utiliser cette approche pour voir combien de dommages un utilisateur pourrait causer sur un système. C'est une bonne idée de vérifier les autorisations de vos fichiers (je viens de découvrir que n'importe quel utilisateur pouvait supprimer toute ma collection de musique, par exemple).


Vous pouvez consulter la base de données avec accessdb. Voici quelques enregistrements aléatoires:

$ accessdb | shuf -n3
fpurge -> "- 3 3 1380819168 A - - gz purge a stream"
fcgetlangs -> "FcGetLangs 3 3 1402007131 A - - gz Get list of languages"
ipython -> "- 1 1 1393443907 A - - gz Tools for Interactive Computing in Python."

Bien que cela ne soit pas tout à fait clair à partir de ce qui précède, il y a en fait des champs séparés par des tabulations:

<name> -> <ext> <sec> <mtime> <ID> <ref> <comp> <whatis> 

Vous pouvez en savoir plus sur le contenu réel du champ dans le manuel technique .


3
Peut-être pourriez-vous ajouter une explication de la raison pour laquelle ce service (et bien d'autres) a son propre utilisateur et n'est pas simplement exécuté en tant que root ou quelque chose?
Thomas Padron-McCarthy

@ ThomasPadron-McCarthy Assez approfondi?
Oli

C'est excellent!
Thomas Padron-McCarthy
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.