Quels sont les dangers de créer un utilisateur normal avec un UID <500?

Quels sont les dangers de créer un utilisateur normal avec un UID <500? En supposant que les UID ne sont pas des doublons des UID existants, qu'est-ce qui pourrait mal tourner?

Ce n'est pas quelque chose que je veux faire, mais quelque chose que j'ai vu et que je veux savoir pourquoi cela ne devrait pas être fait. Dans cet exemple, c'est sur RHEL5.

Je ne crois pas qu'il y ait un risque inhérent, c'est quelque chose qui est fait simplement pour créer une séparation entre ce qui est considéré comme un compte système et un compte utilisateur. D'après mon expérience, la pratique consistant à utiliser des nombres inférieurs à 500 est un redhatisme, et rien de plus.

Sur Solaris, j'avais vu des utilisateurs se voir attribuer des numéros commençant à 100, seulement des années plus tard, je découvrais que lorsque la fusion des systèmes de 2 départements plus petits provoquait un cauchemar, car il y avait plusieurs utilisateurs dans les 2 départements qui avaient le même UID / GID attribué.

C'est vraiment le principal risque / casse-tête lors de l'attribution des UID. Étant donné que l'UID est ce qui est finalement écrit dans l'inode pour les fichiers / répertoires donnés par un utilisateur, vous ne devez pas avoir à effectuer des findrecherches massives pour les fichiers appartenant à l'UID 1234 et les changer en 5678 .

Ainsi, en réfléchissant à la sélection des UID, les administrateurs peuvent éviter les maux de tête sur la route.

L'utilisation de 500 et plus n'est qu'une tentative de Redhat (et d'autres Unix) de se donner suffisamment de tampon pour que les comptes système qui pourraient avoir besoin d'être créés ne soient pas mélangés avec les UID attribués aux utilisateurs.

/etc/login.defs

Soit dit en passant, le nombre 500 est entraîné par ce paramètre dans le fichier de configuration, /etc/login.defs.

#
# Min/max values for automatic uid selection in useradd
#
UID_MIN           500
UID_MAX         60000

#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN           500
GID_MAX         60000

Vous pouvez changer cela en tout ce que vous voulez, si vous souhaitez remplacer le comportement par défaut par useradd/ addusercommandes.

Page de manuel Useradd

Si vous regardez la useraddpage de manuel, vous remarquerez cette partie qui traite de la valeur par défaut de GID, mais ce commentaire s'applique également aux UID:

extrait

-g, --gid GROUP
    The group name or number of the user´s initial login group. The group name 
    must exist. A group number must refer to an already existing group.

    If not specified, the behavior of useradd will depend on the USERGROUPS_ENAB 
    variable in /etc/login.defs. If this variable is set to yes 
    (or -U/--user-group is specified on the command line), a group will be 
    created for the user, with the same name as her loginname. If the variable 
    is set to no (or -N/--no-user-group is specified on the command line), 
    useradd will set the primary group of the new user to the value specified by 
    the GROUP variable in /etc/default/useradd, or 100 by default.

Comptes système

Une autre chose à noter dans la useraddpage de manuel est ce bit sur la génération de compte système.

extrait

-r, --system
    Create a system account.

    System users will be created with no aging information in /etc/shadow, 
    and their numeric identifiers are choosen in the SYS_UID_MIN-SYS_UID_MAX 
    range, defined in /etc/login.defs, instead of UID_MIN-UID_MAX (and their 
    GID counterparts for the creation of groups).

    Note that useradd will not create a home directory for such an user, 
    regardless of the default setting in /etc/login.defs (CREATE_HOME). You 
    have to specify the -m options if you want a home directory for a system 
    account to be created.

C'est cette méthode ( useradd -r ...) souvent utilisée par les scripts qui est intégrée dans les différents gestionnaires de packages, tels que RPM, lorsqu'un package est installé. Le scriptage de cette façon permet au système de sélectionner automatiquement le prochain UID / GID disponible sur un système donné sans risque de marcher sur les UID / GID déjà attribués aux utilisateurs du système.

Du point de vue du noyau, il n'y a qu'un seul utilisateur spécial: UID 0. Le fractionnement des plages d'UID pour des raisons administratives vous simplifie la vie. Les gammes communes sont fournisseur, système, local, global.

Les utilisateurs du fournisseur sont installés lors de l'installation initiale du système et sont gérés de manière statique par le fournisseur. les utilisateurs du système sont installés par machine en fonction des packages installés. la plupart des utilitaires d'ajout / suppression d'utilisateurs ont une limite de plage pour les gérer séparément. les utilisateurs locaux sont des utilisateurs réguliers et affectés par machine. les utilisateurs globaux sont affectés par une base de données centrale, mais sont des utilisateurs réguliers. l'utilisation des plages UID empêche les conflits entre ces différents groupes. où ces seuils peuvent varier, mais est généralement configurable.

Il n'y a aucun danger inhérent à faire cela. Si vous créez un utilisateur avec l'UID 499, il n'aura pas de privilèges supplémentaires. La raison pour laquelle il est suggéré de ne pas le faire est simplement parce que les UID sont généralement réservés aux utilisateurs du système. Le problème que l'on peut rencontrer lors de la création d'un tel UID est lorsqu'un service système s'attend à ce que l'UID soit disponible. C'est un peu comme créer un nouveau service qui s'exécute sur un port bien connu - il n'y a pas nécessairement de problème, mais ce n'est pas une bonne pratique et peut causer des problèmes plus tard lorsque vous configurez sshd, ftpd, etc.

Cela dit, j'ai vu de nombreux systèmes où les utilisateurs ont été créés avec UID <500 sans problème. Cependant, à mesure que la base d'utilisateurs augmente et qu'il y a maintenant des milliers d'utilisateurs, il peut devenir difficile de différencier les comptes d'utilisateurs des comptes système. En suivant la règle sans UID <500, c'est très facile. C'est donc une bonne façon d'organiser les comptes également.

Il n'y a pas de réel danger. Le noyau ne se soucie pas des valeurs d'ID utilisateur sauf 0. La plupart des outils d'administration ne se soucient pas non plus - très peu de parties du système font une différence entre les utilisateurs du système et les utilisateurs humains.

Les utilisateurs du système ont tendance à avoir des groupes dédiés, il est donc peu probable qu'ils créent des comptes appartenant à plus de groupes qu'ils ne le devraient.

Certaines distributions réservent la plage 1–499 (Red Hat et apparentés) ou 1–999 (Debian et apparentés) aux utilisateurs du système, y compris les utilisateurs alloués lors de l'installation d'un paquet contenant un service système qui nécessite un utilisateur dédié. La convention de Debian est que la plage 1–99 est allouée statiquement (donc la création d'un utilisateur humain dans cette plage est une très mauvaise idée car elle peut entrer en conflit avec un utilisateur système) tandis que la plage 100–999 est allouée dynamiquement (donc la création d'un utilisateur humain dans cette plage est inoffensif, car tout nouvel utilisateur du système choisira un ID utilisateur gratuit).

Vous pouvez rencontrer des inconvénients mineurs, tels que les gestionnaires d'affichage n'offrant pas aux utilisateurs dont les UID sont inférieurs au seuil de leur liste.

Le principal danger pour une machine isolée est que vous risquez de confondre vos collègues administrateurs système. Pour une machine d'un réseau où les ID utilisateur sont partagés, vous pouvez rencontrer des conflits avec d'autres machines où ces utilisateurs ont le même ID utilisateur qu'un utilisateur système. Dans les réseaux avec des ID utilisateur partagés, il est préférable de s'en tenir à la plage 1000–65533 ou même 10000–65533 pour les utilisateurs humains.