-bash: / dev / null: autorisation refusée

30

J'essaie de créer un nouvel utilisateur sur un système Centos 6.

Tout d'abord, je fais

useradd kevin

Ensuite, j'ai essayé d'exécuter des commandes en tant qu'utilisateur

su - kevin

Cependant, j'obtiens les messages d'erreur suivants

-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
[kevin@gazelle ~]$

Et je ne peux pas faire grand-chose en tant qu'utilisateur.

Les autorisations sur /dev/nullsont les suivantes:

-rwxr-xr-x  1 root root           9 Jul 25 17:07 null

À peu près les mêmes que sur mon Mac,

crw-rw-rw-   1 root   wheel         3,   2 Jul 25 14:08 null

C'est possible , mais vraiment peu probable, que j'aie touché le dev.

En tant qu'utilisateur root, j'ai essayé d'ajouter kevinau rootgroupe:

usermod -a -G root kevin

Mais je reçois toujours /dev/null erreurs d'autorisation refusée.

Pourquoi le nouvel utilisateur ne peut-il pas écrire /dev/null?
De quels groupes le nouvel utilisateur devrait-il faire partie?
Suis-je pas usurper l'identité de l'utilisateur correctement?
Existe-t-il un guide pour les débutants pour configurer les utilisateurs / autorisations sous Linux?

permissions

— Kevin Burke
source

1

On dirait que / dev / null a été changé en un fichier ordinaire de 9 octets; il est censé être un fichier de périphérique («c» au début du champ type de fichier / bits d'autorisation). Si vous cat /dev/null, cela ressemble-t-il à quelque chose que vous avez récemment utilisé?

— Mark Plotnick

ah. oui. "* maître". voulez-vous ajouter cela comme réponse et je vais le marquer?

— Kevin Burke

Vous pouvez redémarrer et / dev / null sera refait, mais savez-vous ce qui est arrivé à changer / dev / null dans un fichier? Ce serait pénible si cela se reproduisait.

— Mark Plotnick

1

Je suppose que j'ai déplacé la sortie de "git branch" vers / dev / null au lieu de l'écrire, ou que j'avais un mauvais script ou quelque chose

— Kevin Burke

56

Quelqu'un a évidemment déplacé un fichier normal vers / dev / null. Le redémarrage le recréera, ou fera

rm -f /dev/null; mknod -m 666 /dev/null c 1 3

Comme @Flow l'a noté dans un commentaire, vous devez le rootfaire.

— Mark Plotnick
source

12

Si par "quelqu'un" vous voulez dire "moi", alors oui :)

— Kevin Burke

Même j'ai couru le même problème sur le serveur. ubuntu 14.04 LTS. Mais je n'ai pas modifié les autorisations. Y a-t-il une possibilité où je peux suivre quel processus a changé les autorisations?

— Mani

@Mani Linux par défaut n'enregistre pas de si petites modifications, mais vous pouvez activer l'audit pour les voir à partir de maintenant. Comment détecter sur Linux chmod d'un fichier

— Mark Plotnick

1

La solution résout le problème mais le problème se reproduit. Pourquoi?

— Abhishek Soni

@AbhishekSoni Vous pouvez essayer l'audit, comme décrit dans Afficher l'historique d'un fichier (liste des utilisateurs qui ont modifié un fichier)

— Mark Plotnick

13

Cela devrait résoudre le problème (en tant que root):

rm /dev/null
mknod /dev/null c 1 3
chmod 666 /dev/null

— jlliagre
source

2

Celui-ci fonctionne également sur Mac / BSD

— redolent le

3

La solution suggérée par Mark ne fonctionnait pas sur OpenBSD. toutefois

mknod -m 666 /dev/null -c 2 2

a fait l'affaire. J'ai testé cela sur OpenBSD 5.6. Lorsque la réponse acceptée est exécutée, / dev / null bloquera et décevra très mal toute lecture de code.

— meschi
source

L'OP n'a-t-il pas utilisé CentOS plutôt que OpenBSD?

— ott--

3

Malheureusement, différents systèmes d'exploitation utilisent différents nombres majeurs / mineurs pour /dev/null, et il n'y a pas de norme. OP interrogé sur CentOS 6. Linux a utilisé 1,3pour / dev / null retour à au moins 2001. Sur FreeBSD, je l' ai vu 0,6, 15,0, 17,0et 20,0. OpenBSD utilise 2,2. Sur OpenBSD, vous n'avez en fait pas besoin de connaître les chiffres; vous pouvez courir # cd /dev; ./MAKEDEV std.

— Mark Plotnick

Les nombres majeurs et mineurs ne sont pas transportables entre les systèmes d'exploitation. Ce qui fonctionne sous Linux ne fonctionne généralement pas sur * BSD ou Mac OS X (ou Solaris, AIX, HP-UX,…), et vice versa. Vous devez trouver les bons numéros à utiliser dans la mknodcommande en examinant les manuels (si vous êtes chanceux, les informations sont là) ou en examinant les en-têtes du noyau.

— Jonathan Leffler

1

Cela m'est arrivé sur les fenêtres de l'application Ubuntu, tout en essayant d'exécuter un script qui a écrit dans /dev/null. Les autorisations étaient correctes pour /devet /dev/null.

Il s'est avéré que le problème était les sauts de ligne Windows dans le fichier de script. Fonctionnement :

dos2unix.exe c:\path\to\script.sh

Résolu le problème pour moi.

— Arthur.V
source

0

Publication de la réponse Mac OS X pour la postérité ...

sudo su \
&& rm -rf /dev/null \
&& mknod /dev/null c 3 2 \
&& chmod 666 /dev/null

— julien
source