-bash: / dev / null: permiso denegado

30

Estoy tratando de crear un nuevo usuario en un sistema Centos 6.

Primero lo hago

useradd kevin

Entonces, traté de ejecutar comandos como ese usuario

su - kevin

Sin embargo, recibo los siguientes mensajes de error

-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 ~]$

Y no puedo hacer mucho como ese usuario.

Los permisos en /dev/nullson los siguientes:

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

Aproximadamente lo mismo que en mi Mac,

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

Es posible , pero realmente poco probable, que haya tocado el desarrollo.

Como usuario root, intenté agregar kevinal rootgrupo:

usermod -a -G root kevin

Sin embargo, todavía recibo /dev/nullpermisos denegados errores.

¿Por qué no puede escribir el nuevo usuario /dev/null?
¿De qué grupos debe formar parte el nuevo usuario?
¿No estoy suplantando al usuario correctamente?
¿Existe una guía para principiantes para configurar usuarios / permisos en Linux?

permissions

— Kevin Burke
fuente

1

Parece que / dev / null se cambió a un archivo ordinario de 9 bytes de longitud; se supone que es un archivo de dispositivo ('c' al comienzo del campo de tipo de archivo / bits de permiso). Si es así cat /dev/null, ¿se parece a algo que utilizó recientemente?

— Mark Plotnick

ah sí lo hizo. "* maestro". ¿quieres agregar eso como respuesta y lo marcaré?

— Kevin Burke

Puede reiniciar y / dev / null se rehacerá, pero ¿sabe qué sucedió al cambiar / dev / null en un archivo? Sería un dolor si sucediera de nuevo.

— Mark Plotnick

1

Mi conjetura es que moví el resultado de "git branch" a / dev / null en lugar de escribirlo, o tuve un script incorrecto o algo así

— Kevin Burke

56

Evidentemente, alguien movió un archivo normal a / dev / null. Reiniciar lo recreará, o lo hará

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

Como @Flow ha notado en un comentario, debes roothacerlo.

— Mark Plotnick
fuente

12

Si por "alguien" te refieres a "yo", entonces sí :)

— Kevin Burke

Incluso me encontré con el mismo problema en el servidor. ubuntu 14.04 LTS. Pero no cambié los permisos. ¿Hay alguna posibilidad de que pueda rastrear qué proceso cambió los permisos?

— Mani

@Mani Linux por defecto no registra cambios tan pequeños, pero puede activar la auditoría para verlos a partir de ahora. Cómo detectar en Linux chmod de un archivo

— Mark Plotnick

1

La solución soluciona el problema pero el problema vuelve a ocurrir. ¿Por qué?

— Abhishek Soni

@AbhishekSoni Puede intentar la auditoría, como se describe en Mostrar el historial de un archivo (lista de usuarios que han modificado un archivo)

— Mark Plotnick

13

Esto debería solucionar el problema (como root):

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

— jlliagre
fuente

2

Este también funciona en Mac / BSD

— redolente

3

La solución sugerida por Mark no funcionó en OpenBSD. sin embargo

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

Hizo el truco. He probado esto en OpenBSD 5.6. Cuando se ejecuta la respuesta aceptada / dev / null bloqueará y atornillará cualquier lectura de código bastante mal.

— meschi
fuente

¿El OP no usó CentOS en lugar de OpenBSD?

— ott--

3

Desafortunadamente, diferentes sistemas operativos usan diferentes números mayores / menores para /dev/null, y no hay un estándar. OP preguntó sobre CentOS 6. Linux ha utilizado 1,3para / dev / null que se remonta a por lo menos 2001. En FreeBSD, que he visto 0,6, 15,0, 17,0, y 20,0. Usos de OpenBSD 2,2. En OpenBSD, en realidad no necesita saber los números; puede ejecutar # cd /dev; ./MAKEDEV std.

— Mark Plotnick

Los números mayores y menores no son transportables entre sistemas operativos. Lo que funciona en Linux no suele funcionar en * BSD o Mac OS X (o Solaris, AIX, HP-UX, ...), y viceversa. Debe encontrar los números correctos para usar en el mknodcomando mediante el escrutinio de los manuales (si tiene suerte, la información está allí) o mediante el escrutinio de los encabezados del núcleo.

— Jonathan Leffler

1

Esto me sucedió en Windows dentro de la aplicación Ubuntu, mientras intentaba ejecutar un script que escribía en /dev/null. Los permisos fueron correctos para ambos /devy /dev/null.

Resultó que el problema eran las nuevas líneas de Windows en el archivo de script. Corriendo :

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

Resolvió el problema por mí.

— Arthur.V
fuente

0

Publicando la respuesta de Mac OS X para la posteridad ...

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

— Julian
fuente