-bash: / dev / null: permissão negada

30

Estou tentando criar um novo usuário em um sistema Centos 6.

Primeiro eu faço

useradd kevin

Então, tentei executar comandos como esse usuário

su - kevin

No entanto, recebo as seguintes mensagens de erro

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

E eu não posso fazer muito como esse usuário.

As permissões /dev/nullsão as seguintes:

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

Aproximadamente o mesmo que eles estão no meu Mac,

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

É possível , mas realmente improvável, que eu toquei dev.

Como usuário root, tentei adicionar kevinao rootgrupo:

usermod -a -G root kevin

No entanto, ainda estou recebendo /dev/nullerros de permissão negada.

Por que o novo usuário não pode gravar /dev/null?
De quais grupos o novo usuário deve fazer parte?
Não estou representando o usuário corretamente?
Existe um guia para iniciantes para configurar usuários / permissões no Linux?

permissions

— Kevin Burke
fonte

1

Parece que / dev / null foi alterado para um arquivo comum de 9 bytes; deveria ser um arquivo de dispositivo ('c' no início do campo de tipo de arquivo / bits de permissão). Se você cat /dev/null, parece algo que você usou recentemente?

— precisa

ah sim fez. "* mestre". você quer adicionar isso como resposta e eu vou marcar?

— 22814 Kevin Burke

Você pode reiniciar e / dev / null será refeito, mas você sabe o que aconteceu com a alteração de / dev / null em um arquivo? Seria uma dor se isso acontecesse novamente.

— precisa

1

Meu palpite é que me mudei a saída do "git branch" para / dev / null em vez de escrevê-lo, ou tinha um roteiro ruim ou algo assim

— Kevin Burke

56

Alguém evidentemente moveu um arquivo regular para / dev / null. A reinicialização o recriará ou fará

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

Como o @Flow observou em um comentário, você deve rootfazer isso.

— Mark Plotnick
fonte

12

Se por "alguém" que quer dizer "me", então sim :)

— Kevin Burke

Mesmo eu corri int o mesmo problema no servidor. Ubuntu 14.04 LTS. Mas não mudei as permissões. Existe alguma possibilidade de rastrear qual processo alterou as permissões?

— Mani

Por padrão, o @Mani Linux não registra alterações tão pequenas, mas você pode ativar a auditoria para vê-las a partir de agora. Como detectar no Linux chmod de um arquivo

— Mark Plotnick

1

A solução corrige o problema, mas o problema ocorre novamente. Por quê?

— Abhishek Soni

@AbhishekSoni Você pode tentar auditoria, conforme descrito em Mostrar histórico de um arquivo (lista de usuários que tenha modificado um arquivo)

— Mark Plotnick

13

Isso deve corrigir o problema (como root):

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

— jlliagre
fonte

2

Este também funciona em Mac / BSD

— redolent

3

A solução sugerida por Mark não funcionou no OpenBSD. Contudo

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

fez o truque. Eu testei isso no OpenBSD 5.6. Quando a resposta aceita é executada, o / dev / null irá bloquear e danificar muito a leitura do código.

— meschi
fonte

O OP não usou o CentOS em vez do OpenBSD?

— #

3

Infelizmente, sistemas operacionais diferentes usam números principais / secundários diferentes /dev/nulle não há padrão. OP perguntado sobre CentOS 6. Linux tem usado 1,3para / dev / null voltar para pelo menos 2001. No FreeBSD, eu vi 0,6, 15,0, 17,0, e 20,0. O OpenBSD usa 2,2. No OpenBSD, você realmente não precisa saber os números; você pode correr # cd /dev; ./MAKEDEV std.

— Mark Plotnick

Números principais e secundários não são transportáveis entre sistemas operacionais. O que funciona no Linux geralmente não funciona em * BSD ou Mac OS X (ou Solaris, AIX, HP-UX, ...) e vice-versa. Você precisa encontrar os números corretos para usar no mknodcomando examinando os manuais (se tiver sorte, as informações estão lá) ou examinando os cabeçalhos do kernel.

— Jonathan Leffler

1

Isso aconteceu comigo no Windows, dentro do aplicativo Ubuntu, enquanto tentava executar um script que gravou /dev/null. As permissões estavam corretas para ambos /deve /dev/null.

Acabou que o problema eram as novas linhas do Windows no arquivo de script. Corrida :

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

Resolvido o problema para mim.

— Arthur.V
fonte

0

Publicando a resposta do Mac OS X para posteridade ...

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

— Julian
fonte