-bash: / dev / null: Odmowa uprawnień

30

Próbuję utworzyć nowego użytkownika w systemie Centos 6.

Po pierwsze tak

useradd kevin

Następnie próbowałem uruchomić polecenia jako ten użytkownik

su - kevin

Otrzymuję jednak następujące komunikaty o błędach

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

I nie mogę wiele zrobić jako ten użytkownik.

Uprawnienia /dev/nullsą następujące:

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

Z grubsza takie same, jak na moim komputerze Mac,

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

Jest to możliwe , ale bardzo mało prawdopodobne, że dotknąłem dev.

Jako użytkownik root próbowałem dodać kevindo rootgrupy:

usermod -a -G root kevin

Jednak nadal otrzymuję /dev/nullbłędy odmowy uprawnień.

Dlaczego nowy użytkownik nie może pisać /dev/null?
W jakich grupach powinien być nowy użytkownik?
Czy nie podszywam się pod użytkownika poprawnie?
Czy istnieje przewodnik dla początkujących dotyczący konfigurowania użytkowników / uprawnień w systemie Linux?

permissions Kevin Burke
źródło
1
Wygląda na to, że / dev / null zmieniono na zwykły plik o długości 9 bajtów; ma to być plik urządzenia („c” na początku pola typu pliku / bitów uprawnień). Jeśli tak cat /dev/null, czy wygląda to na coś, czego ostatnio używałeś?
Mark Plotnick,
ah. tak. "* mistrz". chcesz dodać to jako odpowiedź, a ja to zaznaczę?
Kevin Burke,
Możesz zrestartować komputer i / dev / null zostanie przerobiony, ale czy wiesz, co się zmieniło / dev / null w plik? Byłoby to bólem, gdyby to się powtórzyło.
Mark Plotnick,
1
Domyślam się przeniosłem wyjście „git oddziału” do / dev / null zamiast pisać, albo miał zły skrypt lub coś
Kevin Burke

Odpowiedzi:

56

Ktoś najwyraźniej przeniósł zwykły plik do / dev / null. Ponowne uruchomienie go odtworzy lub zrobi

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

Jak zauważył @Flow w komentarzu, musisz rootto zrobić.

Mark Plotnick
źródło
12
Jeśli przez „kogoś” masz na myśli „mnie”, to tak :)
Kevin Burke
Nawet ja uruchomiłem int ten sam problem na serwerze. ubuntu 14.04 LTS. Ale nie zmieniłem uprawnień. Czy jest jakaś możliwość, w której mogę śledzić, który proces zmienił uprawnienia?
Mani,
@Mani Linux domyślnie nie rejestruje tak małych zmian, ale możesz włączyć inspekcję, aby je teraz zobaczyć. Jak wykryć plik chmod w systemie Linux
Mark Plotnick,
1
Rozwiązanie rozwiązuje problem, ale problem występuje ponownie. Czemu?
Abhishek Soni
@AbhishekSoni Możesz spróbować przeprowadzić inspekcję zgodnie z opisem w Wyświetlanie historii pliku (lista użytkowników, którzy zmodyfikowali plik)
Mark Plotnick
13

To powinno rozwiązać problem (jako root):

rm /dev/null
mknod /dev/null c 1 3
chmod 666 /dev/null
jlliagre
źródło
2
Ten działa również na Mac / BSD
ponury
3

Rozwiązanie zaproponowane przez Marka nie działało na OpenBSD. jednak

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

wykonał lewę. Przetestowałem to na OpenBSD 5.6. Po wykonaniu zaakceptowanej odpowiedzi / dev / null bardzo źle blokuje i wkręca odczytany z niej kod.

meschi
źródło
Czy OP nie używał CentOS zamiast OpenBSD?
ott--
3
Niestety różne systemy operacyjne używają różnych numerów głównych / pomocniczych /dev/nulli nie ma standardu. PO pytani o 6. CentOS Linux używany 1,3do / dev / null wracając do co najmniej 2001 roku na FreeBSD, widziałem 0,6, 15,0, 17,0, i 20,0. Używa OpenBSD 2,2. W OpenBSD tak naprawdę nie musisz znać liczb; możesz biegać # cd /dev; ./MAKEDEV std.
Mark Plotnick
Dużych i mniejszych numerów nie można przenosić między systemami operacyjnymi. To, co działa w systemie Linux, zwykle nie działa na * BSD lub Mac OS X (lub Solaris, AIX, HP-UX,…) i odwrotnie. Musisz znaleźć poprawne liczby do użycia w mknodpoleceniu przez sprawdzenie instrukcji (jeśli masz szczęście, informacje tam są) lub przez sprawdzenie nagłówków jądra.
Jonathan Leffler,
1

Zdarzyło mi się to w systemie Windows w aplikacji Ubuntu, podczas próby uruchomienia skryptu, w którym napisano /dev/null. Uprawnienia były poprawne zarówno dla, jak /devi dla /dev/null.

Okazało się, że problemem były nowe wiersze systemu Windows w pliku skryptu. Bieganie :

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

Rozwiązałem problem dla mnie.

Arthur.V
źródło
0

Publikowanie odpowiedzi w systemie Mac OS X dla potomnych ...

sudo su \
&& rm -rf /dev/null \
&& mknod /dev/null c 3 2 \
&& chmod 666 /dev/null
juliański
źródło