Właśnie zdałem sobie sprawę, że mój system nie ogranicza właściwie liczby procesów na użytkownika, a tym samym nie uniemożliwia użytkownikowi zrobienia bomby widelcowej i awarii całego systemu:
user@thebe:~$ cat /etc/security/limits.conf | grep user
user hard nproc 512
user@thebe:~$ ulimit -u
1024
user@thebe:~$ :(){ :|:& };:
[1] 2559
user@thebe:~$ ht-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
...
Connection to thebe closed by remote host.
Czy to błąd lub dlaczego ignoruje limit limits.conf
i dlaczego nie stosuje limitu, który ulimit -n
twierdzi, że jest?
PS: Naprawdę nie sądzę, aby limit pamięci został przekroczony przed limitem procesu. Ta maszyna ma 8 GB pamięci RAM i zużywała tylko 4% w momencie, gdy upuściłem bombę widelcową.
EDYTOWAĆ:
Udało mi się to odtworzyć na płycie CD na żywo. Myślę, że to musi być błąd. Zasadniczo kończy się to zabijaniem wszystkich procesów, w tym krytycznych dla systemu rzeczy, takich jak X11, SSHD itp.
Każdy użytkownik może zawiesić system.
process
ulimit
resource-limiting
d_inevitable
źródło
źródło
ulimit -u
user@thebe:~$ ulimit -u
1024
ulimit -u
, otrzymuję 31325. Kiedy uruchamiamulimit -u 512
, idzie 512. Kiedy uruchamiam tę bombę wideł, reszta mojego systemu jest w porządku.Odpowiedzi:
Okazuje się, że
/etc/security/limits.conf
to działa, ale wymaga ponownego uruchomienia, zanim zostanie zinterpretowane. Wylogowanie nie jest wystarczające.Polecam każdemu ograniczenie pliku konfiguracyjnego, takiego jak
Zastąp
user
dowolną nazwą użytkownika, którą chcesz ograniczyć.Albo lepiej:
Zastąp
group
dowolną grupą użytkowników, którą chcesz ograniczyć.źródło