Réponses:
man
(la commande, pas l'utilisateur) est une application d'aide. Les applications fournissent des pages de manuel dans leurs packages, mais man
doivent savoir où elles se trouvent et quelle aide elles fournissent. Pour accélérer les choses - il man
n'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 mandb
stocke 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 mandb
est exécuté en tant man
qu'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/man
sont toujours root.
Mais pourquoi mandb
fonctionne-t-il en tant qu'utilisateur différent? Il pourrait (probablement) fonctionner aussi bien root
mais 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' man
index 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 .