Quel est le but de l'utilisateur 'personne'?

Après avoir lu la liste de tous les utilisateurs humains, j'ai remarqué qu'il existe un compte d'utilisateur nommé "personne" dans mon système Ubuntu.

De plus, j'ai remarqué que je peux me connecter à ce compte à partir d'un terminal en utilisant la commande suivante et mon mot de passe:

sudo su nobody

Cela ne me dérange pas du tout, mais je veux savoir quel est le but de cet utilisateur? Est-il créé par défaut sur une nouvelle installation d'Ubuntu ou est-il créé en installant un paquet particulier?

Il est là pour exécuter des tâches qui ne nécessitent aucune autorisation spéciale. Il est généralement réservé aux services vulnérables (httpd, etc.) afin que, s’ils sont piratés, ils causent des dommages minimes sur le reste du système.

Si vous optez pour quelque chose qui fonctionne réellement (les serveurs Web sont parfois exploités pour exécuter du code arbitraire), il s’exécuterait en tant que tel et aurait accès à tout ce qu’il possédait. Dans la plupart des cas, cela est aussi grave que d’être root.

Vous pouvez en savoir plus sur l'utilisateur nobody sur le wiki d'Ubuntu:

• https://wiki.ubuntu.com/nobody

Pour répondre à vos suivis:

Pourquoi je ne peux pas accéder à ce compte avec su nobody?

sudo grep nobody /etc/shadowvous montrera que personne n'a pas de mot de passe et que vous ne pouvez pas susans mot de passe de compte. Le moyen le plus propre est de le sudo su nobodyremplacer. Cela vous laissera dans une jolie shcoquille désolée .

Pouvez-vous donner un exemple particulier quand est indiqué d'utiliser ce compte?

Lorsque les autorisations ne sont pas requises pour les opérations d'un programme. Ceci est d'autant plus remarquable qu'il n'y aura jamais d'activité disque.

Un monde réel exemple de ceci est memcached(une valeur de clé cache en mémoire / base de données / chose), assis sur mon ordinateur et mon serveur en cours d' exécution sous le compte personne. Pourquoi? Car il ne nécessite aucune autorisation et lui donner un compte disposant d'un accès en écriture aux fichiers constituerait un risque inutile.

Dans de nombreuses variantes d'Unix, "nobody" est le nom conventionnel d'un compte utilisateur qui ne possède aucun fichier, ne fait partie d'aucun groupe privilégié et n'a aucune autre possibilité que celles de tous les autres utilisateurs.

Il est courant d'exécuter les démons en tant que personne, en particulier les serveurs, afin de limiter les dommages pouvant être causés par un utilisateur malveillant qui en a pris le contrôle. Cependant, l'utilité de cette technique est réduite si plusieurs démons sont exécutés de la sorte, car le contrôle d'un démon permettrait de tous les contrôler. La raison en est que personne ne possède de processus ayant la capacité de s’envoyer des signaux et même de se déboguer, ce qui leur permet de lire ou même de modifier la mémoire de chacun.

Informations tirées de http://en.wikipedia.org/wiki/Nobody_(nom d'utilisateur) .

L'utilisateur nobody est réservé à NFS uniquement.

Les réponses ci-dessus sont plutôt fausses, car elles supposent qu'il nobodys'agit d'un identifiant d'utilisateur "générique" de style anonyme / invité.

Dans le modèle de contrôle d'accès UNIX / Linux, les ID utilisateur de style anonyme / invité n'existent pas et il s'agit de mauvaises suggestions:

• « Commun à exécuter daemons comme nobody, en particulier les serveurs, afin de limiter les dégâts qui pourrait être fait par un utilisateur malveillant qui a gagné le contrôle. » En raison de la qui suit: « Toutefois, l'utilité de cette technique est réduite si plus un démon est exécuté comme ceci, car alors prendre le contrôle d’un démon leur donnerait le contrôle de tous ".
• " Un exemple concret de cela est memcached(cache / base de données / chose dans la mémoire clé), assis sur mon ordinateur et mon serveur fonctionnant sous le nobodycompte. Pourquoi? Parce qu'il n'a simplement pas besoin d'autorisations et le donne un compte disposant d'un accès en écriture aux fichiers ne serait qu'un risque inutile. "

Le nobodynom d'utilisateur portant l'ID utilisateur 65534 a été créé et réservé à des fins spécifiques. Il ne doit être utilisé qu'à cette fin: en tant qu'espace réservé pour les utilisateurs "non mappés" et les ID utilisateur dans les exportations d'arborescence NFS.

Autrement dit, à moins que le mappage utilisateur / identifiant ne soit configuré pour les exportations d'arborescence NFS, tous les fichiers de l'exportation apparaîtront comme appartenant à nobody. Ceci a pour but d'empêcher tous les utilisateurs du système importateur d'accéder à ces fichiers (à moins qu'ils ne disposent d'autorisations "autres"), car aucun d'eux (à l'exception de root) ne peut être / devenir nobody.

C'est donc une très mauvaise idée de l'utiliser nobodyà d' autres fins, car son but est d'être un nom d'utilisateur / ID utilisateur pour les fichiers qui ne doivent être accessibles à personne.

L'entrée du wiki est très fausse aussi.

La pratique UNIX / Linux consiste à créer un nouveau compte pour chaque "application" ou domaine d'application nécessitant un domaine de contrôle d'accès distinct et à ne jamais le réutiliser en nobodydehors de NFS .

L' nobodyutilisateur est créé par défaut lors d'une nouvelle installation (vérifié dans Ubuntu Desktop 13.04).

Dans beaucoup de variantes * nix, nobodyest le nom conventionnel d'un compte utilisateur qui ne possède aucun fichier, ne fait partie d'aucun groupe privilégié et n'a aucune autre possibilité que celles dont disposent tous les autres utilisateurs (l' nobodyutilisateur et le groupe n'ont aucune entrée dans le /etc/sudoersfichier) .

Il est courant d’exécuter des démons en tant que nobodyserveurs, notamment, afin de limiter les dommages pouvant être causés par un utilisateur malveillant qui en a pris le contrôle. Cependant, l'utilité de cette technique est réduite si plusieurs démons sont exécutés de la sorte, car le contrôle d'un démon permettrait de tous les contrôler. La raison en est que les nobodyprocessus propriétaires ont la capacité de s'échanger des signaux et même de se déboguer, leur permettant de lire ou même de modifier la mémoire de chacun.

_{Source : Wikipedia - Personne (nom d'utilisateur)}

Les nobodyprocessus possédés sont capables d’envoyer des signaux et même de se retracer sous Linux, ce qui signifie qu’un processus appartenant à aucune personne ne peut lire et écrire la mémoire d’un autre processus appartenant à une autre personne.

Voici un exemple d'entrée de l' nobodyutilisateur dans le /etc/passwdfichier:

alaa@aa-lu:~$ grep nobody /etc/passwd
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh

Comme vous le remarquerez peut-être, l’ nobodyutilisateur a /bin/shun shell de connexion et /nonexistentun répertoire personnel. Comme son nom l'indique, le /nonexistentrépertoire n'existe pas, par défaut.

Si vous êtes paranoïaque, vous pouvez définir nobodyle shell par défaut comme /usr/sbin/nologinet ainsi, refuser le login SSH pour l' nobodyutilisateur.

_{Source : LinuxG.net - L'utilisateur Nobody sous Linux et Unix}

personne n'est un utilisateur spécial et un compte de groupe. Comme il s'agit d'un nom d'utilisateur réel (et d'un nom de groupe) pouvant être utilisé par les processus et même par les utilisateurs, il ne s'agit littéralement de personne . Par exemple, certaines configurations Apache n'ont personne en tant qu'utilisateur / groupe propriétaire des fichiers et répertoires du site Web. Le problème survient lorsque plusieurs processus peuvent utiliser l'utilisateur nobody, tels que les répertoires NFS et le serveur Web.

Correction mineure à ' L'utilisateur nobody est réservé à NFS uniquement. ' répondre. L' nobodyutilisateur est également utilisé pour les conteneurs non privilégiés avec des montages liés à ce stade.

Cela provient de systemd-nspawn, plus précisément de l'option de montage --bind:

Notez que lorsque cette option est utilisée en association avec --private-users, les points de montage résultants seront la propriété de l'utilisateur nobody. En effet, le montage, ainsi que ses fichiers et répertoires, continuent d’être la propriété des utilisateurs et groupes d’hôtes appropriés, qui n’existent pas dans le conteneur, et apparaissent donc sous l’identificateur générique UID 65534 (personne). Si de tels montages de liaison sont créés, il est recommandé de les rendre en lecture seule, en utilisant --bind-ro =.

systemd-nspawn