Comment le paquet Debian doit-il créer des comptes utilisateurs?


33

Le paquet qqq.debinstalle le programme qqqqui doit être exécuté à partir d' uqqqun compte utilisateur. Le paquet comprend le qqqprogramme, le qqq.conffichier de configuration et /etc/init.d/qqqinitscript.

Comment le paquet devrait-il gérer la création d'utilisateur uqqq? Existe-t-il des meilleures pratiques ou des directives officielles à ce sujet?

  1. Il suffit de créer l'utilisateur automatiquement uqqqdans postinst;
  2. Créez automatiquement l'utilisateur au premier démarrage à partir du /etc/init.d/qqqscript;
  3. Créer automatiquement l'utilisateur au premier démarrage du qqqprogramme (sans argument)
  4. Ne créez aucun compte d'utilisateur, refusez de démarrer sauf si l'utilisateur est explicitement créé par l'administrateur (par exemple, using qqq --create-user);
  5. Ne créez pas de compte utilisateur, exécutez par défaut de manière non sécurisée à partir de root;
  6. Interactively demande à postinst, au script init.d ou à qqqlui - même si un utilisateur doit être créé.

Le package doit-il supprimer le compte utilisateur lors de la désinstallation?


7
Le moyen le plus simple est de répondre aux questions de cette question en consultant les scripts de pré / post-installation des paquets Debian officiels. Il suffit d’exécuter grep adduser /var/lib/dpkg/info/*.postinstsur n’importe quel système basé sur Debian pour obtenir de nombreux exemples.
Jofel

Quand adduserest utilisé, il doit également dépendre du paquet. Voir: lintian.debian.org/tags/…
Lekensteyn le

Réponses:


22

Le wiki Debian contient des instructions plus complètes et spécifiques que le manuel de politique Debian déjà mentionné. Voir AccountHandlingInMaintainerScripts :

Le programme adduser agit correctement s'il est appelé avec l'option --system. Il est donc généralement nécessaire d'appeler le

adduser --system $ USERNAME

dans votre postinst pour créer le compte avec les connexions désactivées, un groupe principal de nogroup et un répertoire personnel sous / home. Si vous voulez d'autres options, ajoutez-les comme vous le souhaitez.

Normalement, il ne devrait pas être nécessaire de vérifier avec getent si un compte existe déjà, car adduser --system fait généralement le bon choix. Si ce n'est pas le cas, veuillez signaler un bogue à adduser pour que vos scripts de responsable restent simples.

Les conseils qu'il donne sur la suppression de comptes ne sont pas concluants. Cependant, je noterai que l’ avis correspondant pour fedora n’est pas équivoque.

Ne pas supprimer des utilisateurs ou des groupes Nous ne supprimons jamais des utilisateurs ou des groupes créés par des packages. Il n'y a aucun moyen sensé de vérifier si les fichiers appartenant à ces utilisateurs / groupes sont laissés derrière (et même si nous le ferions, que ferions-nous avec eux?) lorsqu'un utilisateur / groupe sémantiquement non lié est créé ultérieurement et réutilise l'UID / le GID. En outre, dans certaines configurations, la suppression de l'utilisateur / du groupe peut ne pas être possible et / ou souhaitable (par exemple, lors de l'utilisation d'une base de données partagée / utilisateur / groupe distante). Le nettoyage des utilisateurs / groupes inutilisés est laissé au soin des administrateurs système s’ils le souhaitent.


12

En tant qu'administrateur installant des packages, mes packages créeraient automatiquement les utilisateurs dont ils ont besoin pré ou postinst, de sorte que tous les fichiers devant appartenir à l'utilisateur puissent être créés avant l'exécution du programme.

Votre programme ne doit être exécuté en tant que root que s'il en a le besoin (par exemple, une liaison avec un port privilégié) et, idéalement, il devrait abandonner ses privilèges une fois que l'utilisateur a terminé la tâche requise.

Vous pouvez voir comment d’autres packages (installés) ont géré cela en utilisant

grep -l adduser /var/lib/dpkg/info/*postinst /var/lib/dpkg/info/*preinst

et lire les fichiers listés (la plupart prennent plus d’une ligne d’options).

Curieusement, tous les packages installés adduser, à l'exception d' un seul, qui créent une utilisation par l'utilisateur pour ajouter des utilisateurs, mais le package adduser n'est pas un package requis; votre package devra donc être construit pour en dépendre. Le useraddprogramme est utilisé par le paquet libuuid1 et fait partie du passwdpaquet qui est un paquet requis.


1
C'est terrible, vérifiez la bonne façon de générer les scripts preinst plutôt que de les pirater manuellement.
LtWorf

l' --quietapproche semble très populaire
vidstige

6

Section 10.9. Les autorisations et les propriétaires dans le manuel de la politique Debian correspondent à ce que vous recherchez (à partir de "version 3.9.5.0, 2013-10-28"):

Si vous devez créer un nouvel utilisateur ou un nouveau groupe pour votre package, il existe deux possibilités. Tout d’abord, vous devrez peut-être attribuer à cet utilisateur ou à ce groupe la propriété de certains fichiers du paquet binaire, ou vous devrez peut-être compiler l’identifiant de l’utilisateur ou du groupe (plutôt que son nom) dans le binaire (bien que ce dernier soit à éviter si possible, car dans ce cas, vous avez besoin d’un identifiant alloué statiquement).

Si vous avez besoin d'un identifiant alloué statiquement, vous devez demander un identifiant d'utilisateur ou de groupe au base-passwd' maintainer, and must not release the package until you have been allocated one. Once you have been allocated one you must either make the package depend on a version of thepaquetage base-passwd 'avec l'identifiant présent dans /etc/passwd' or / etc / group', ou demander à votre paquet de créer lui-même l'utilisateur ou le groupe avec le code correct. id (utiliser adduser') in itspreinst 'ou postinst'. (Doing it in thepostinst' est préférable si c'est possible, sinon une prédédépendance sera nécessaire sur le paquet `adduser '.)

Note: La liste debian-devel est très actif et répond à des questions aussi (bien que cet exemple est de 2003).


3
Donc, la réponse simplifiée courte est "Utiliser adduserdans postinst".
Vi.
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.