-bash: / dev / null: autorizzazione negata

30

Sto cercando di creare un nuovo utente su un sistema Centos 6.

Prima di tutto

useradd kevin

Quindi, ho provato a eseguire comandi come quell'utente

su - kevin

Tuttavia, ricevo i seguenti messaggi di errore

-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 non posso fare molto come quell'utente.

Le autorizzazioni su /dev/nullsono le seguenti:

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

Più o meno come sul mio Mac,

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

È possibile , ma davvero improbabile, che abbia toccato dev.

Come utente root, ho provato ad aggiungere kevinal rootgruppo:

usermod -a -G root kevin

Tuttavia sto ancora ricevendo /dev/nullerrori di autorizzazione negata.

Perché il nuovo utente non può scrivere /dev/null?
Di quali gruppi dovrebbe far parte il nuovo utente?
Non sto impersonando l'utente correttamente?
Esiste una guida per principianti alla configurazione di utenti / autorizzazioni su Linux?

permissions

— Kevin Burke
fonte

1

Sembra che / dev / null sia stato modificato in un file ordinario lungo 9 byte; dovrebbe essere un file di dispositivo ('c' all'inizio del campo tipo di file / bit di autorizzazione). Se cat /dev/nullsì, sembra qualcosa che hai usato di recente?

— Mark Plotnick, il

ah. sì, l'ha fatto. "* maestro". vuoi aggiungerlo come risposta e lo segnerò?

— Kevin Burke,

Puoi riavviare e / dev / null verrà rifatto, ma sai cosa è successo a cambiare / dev / null in un file? Sarebbe un dolore se accadesse di nuovo.

— Mark Plotnick, il

1

La mia ipotesi è che ho spostato l'output di "git branch" in / dev / null invece di scriverlo, o ho avuto un brutto script o qualcosa del genere

— Kevin Burke,

56

Qualcuno ha evidentemente spostato un file normale in / dev / null. Il riavvio lo ricrea o lo farà

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

Come ha notato @Flow in un commento, devi rootfarlo.

— Mark Plotnick
fonte

12

Se per "qualcuno" intendi "me", allora sì :)

— Kevin Burke,

Anche io ho riscontrato lo stesso problema sul server. ubuntu 14.04 LTS. Ma non ho cambiato i permessi. C'è qualche possibilità in cui posso monitorare quale processo ha modificato le autorizzazioni?

— Mani,

@Mani Linux di default non registra tali piccole modifiche, ma puoi attivare il controllo per vederle d'ora in poi. Come rilevare su Linux chmod di un file

— Mark Plotnick,

1

La soluzione risolve il problema ma il problema si ripresenta. Perché?

— Abhishek Soni,

@AbhishekSoni Potresti provare a controllare, come descritto in Visualizza la cronologia di un file (elenco di utenti che hanno modificato un file)

— Mark Plotnick,

13

Questo dovrebbe risolvere il problema (come root):

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

— jlliagre
fonte

2

Questo funziona anche su Mac / BSD

— redolent l'

3

La soluzione suggerita da Mark non ha funzionato su OpenBSD. tuttavia

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

ha fatto il trucco. Ho provato questo su OpenBSD 5.6. Quando la risposta accettata viene eseguita / dev / null bloccherà e rovinerà qualsiasi codice da leggere piuttosto male.

— Meschi
fonte

L'OP non ha usato CentOS anziché OpenBSD?

— ott--

3

Sfortunatamente, diversi sistemi operativi usano numeri maggiori / minori diversi per /dev/null, e non esiste uno standard. OP ha chiesto di CentOS 6. Linux è utilizzato 1,3per il / dev / null che risale almeno al 2001. FreeBSD, ho visto 0,6, 15,0, 17,0, e 20,0. OpenBSD utilizza 2,2. Su OpenBSD, in realtà non è necessario conoscere i numeri; puoi correre # cd /dev; ./MAKEDEV std.

— Mark Plotnick,

I numeri maggiori e minori non sono trasportabili tra i sistemi operativi. Ciò che funziona su Linux di solito non funziona su * BSD o Mac OS X (o Solaris, AIX, HP-UX, ...) e viceversa. Devi trovare i numeri corretti da usare nel mknodcomando esaminando i manuali (se sei fortunato, le informazioni sono lì) o esaminando le intestazioni del kernel.

— Jonathan Leffler

1

Questo mi è successo su Windows all'interno dell'applicazione Ubuntu, mentre cercavo di eseguire uno script in cui scrivevo /dev/null. Le autorizzazioni erano corrette per entrambi /deve /dev/null.

Si è scoperto che il problema erano le nuove righe di Windows nel file di script. In esecuzione :

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

Risolto il problema per me.

— Arthur.V
fonte

0

Pubblicare la risposta di Mac OS X per i posteri ...

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

— giuliano
fonte