-bash: / dev / null: Berechtigung verweigert

30

Ich versuche, einen neuen Benutzer auf einem Centos 6-System zu erstellen.

Zuerst tue ich

useradd kevin

Dann habe ich versucht, Befehle als dieser Benutzer auszuführen

su - kevin

Ich erhalte jedoch die folgenden Fehlermeldungen

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

Und ich kann nicht viel als dieser Benutzer tun.

Die Berechtigungen für /dev/nullsind wie folgt:

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

Etwa genauso wie auf meinem Mac,

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

Es ist möglich , aber sehr unwahrscheinlich, dass ich dev berührt habe.

Als Root-Benutzer habe ich versucht, Folgendes kevinzur rootGruppe hinzuzufügen :

usermod -a -G root kevin

Ich erhalte jedoch immer noch die /dev/nullErlaubnis, Fehler zu verweigern.

Warum kann der neue Benutzer nicht schreiben /dev/null?
Zu welchen Gruppen soll der neue Benutzer gehören?
Bin ich nicht korrekt imitiert?
Gibt es eine Anleitung für Anfänger zum Einrichten von Benutzern / Berechtigungen unter Linux?

permissions

— Kevin Burke
quelle

1

Es sieht so aus, als ob / dev / null in eine gewöhnliche 9-Byte-Datei geändert wurde. Es soll eine Gerätedatei sein ('c' am Anfang des Felds Dateityp / Berechtigungsbits). Wenn ja cat /dev/null, sieht es nach etwas aus, das Sie kürzlich benutzt haben?

— Mark Plotnick

Ah. ja, tat es. "* Meister". Möchtest du das als Antwort hinzufügen und ich werde es markieren?

— Kevin Burke

Sie können neu starten und / dev / null wird neu erstellt, aber wissen Sie, was passiert ist, um / dev / null in eine Datei zu ändern? Es wäre ein Schmerz, wenn es wieder passieren würde.

— Mark Plotnick

1

Ich schätze, ich habe die Ausgabe von "git branch" nach / dev / null verschoben, anstatt sie zu schreiben, oder ich hatte ein schlechtes Skript oder so

— Kevin Burke

56

Offensichtlich hat jemand eine reguläre Datei nach / dev / null verschoben. Durch einen Neustart wird es neu erstellt oder ausgeführt

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

Wie @Flow in einem Kommentar vermerkt hat, müssen Sie dies roottun.

— Mark Plotnick
quelle

12

Wenn mit "jemand" meinst du "ich", dann ja :)

— Kevin Burke

Sogar ich habe das gleiche Problem auf dem Server ausgeführt. Ubuntu 14.04 LTS. Berechtigungen habe ich aber nicht geändert. Gibt es eine Möglichkeit, wo ich verfolgen kann, welcher Prozess die Berechtigungen geändert hat?

— Mani

@Mani Linux protokolliert standardmäßig keine so kleinen Änderungen, aber Sie können die Überwachung aktivieren, um sie von nun an anzuzeigen. Wie auf Linux chmod einer Datei zu erkennen

— Mark Plotnick

1

Die Lösung behebt das Problem, das Problem tritt jedoch erneut auf. Warum?

— Abhishek Soni

@AbhishekSoni Sie können versuchen, eine Prüfung durchzuführen, wie unter Anzeigen des Dateiversionsverlaufs (Liste der Benutzer, die eine Datei geändert haben)

— Mark Plotnick

13

Dies sollte das Problem beheben (als root):

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

— jlliagre
quelle

2

Dieser funktioniert auch auf Mac / BSD

— redolent

3

Die von Mark vorgeschlagene Lösung funktionierte unter OpenBSD nicht. jedoch

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

hat den Trick gemacht. Ich habe dies unter OpenBSD 5.6 getestet. Wenn die akzeptierte Antwort ausgeführt wird, blockiert / dev / null jeden Code, der daraus gelesen wird, und macht ihn unsicher.

— Meschi
quelle

Hat das OP nicht CentOS anstatt OpenBSD benutzt?

— ott--

3

Leider verwenden unterschiedliche Betriebssysteme unterschiedliche Haupt- / Nebennummern für /dev/nullund es gibt keinen Standard. OP fragte nach CentOS 6. Linux verwendet hat 1,3für / dev / null zu gehen zurück mindestens 2001 auf FreeBSD, ich habe gesehen 0,6, 15,0, 17,0, und 20,0. OpenBSD verwendet 2,2. Unter OpenBSD müssen Sie die Zahlen eigentlich nicht kennen. du kannst rennen # cd /dev; ./MAKEDEV std.

— Mark Plotnick

Major- und Minor-Nummern können nicht zwischen Betriebssystemen transportiert werden. Was unter Linux funktioniert, funktioniert normalerweise nicht unter * BSD oder Mac OS X (oder Solaris, AIX, HP-UX,…) und umgekehrt. Sie müssen die richtigen Zahlen für den mknodBefehl finden, indem Sie die Handbücher überprüfen (wenn Sie Glück haben, sind die Informationen dort) oder indem Sie die Kernel-Header überprüfen.

— Jonathan Leffler

1

Dies passierte mir unter Windows in der Ubuntu-Anwendung, als ich versuchte, ein Skript auszuführen, in das geschrieben wurde /dev/null. Berechtigungen waren für beide /devund korrekt /dev/null.

Es stellte sich heraus, dass das Problem Windows-Zeilenumbrüche in der Skriptdatei waren. Laufen :

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

Löste das Problem für mich.

— Arthur.V
quelle

0

Die Antwort von Mac OS X für die Nachwelt veröffentlichen ...

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

— julianisch
quelle