Jeśli przed zainstalowaniem nowej biblioteki będzie , myślę, że Twój system będzie przechowywać i-węzeł przydzielony, plik otwarty, a twój program uruchomiony. (A kiedy twój program w końcu się zakończy, wtedy zostaną ukryte głównie ukryte, ale wciąż dostępne zasoby plików.)
Aktualizacja: OK, doprecyzowanie. Dynamiczny linker faktycznie całkowicie "rozwiązuje" ten problem, przekazując flagę MAP_COPY, jeśli jest dostępna, do mmap(2). Jednak wersja MAP_COPY nie istnieje w systemie Linux i nie jest planowaną przyszłością. Drugi najlepszy to MAP_DENYWRITE, który, jak sądzę, używa program ładujący, który jest w Linuksie API i który Linux robił. Występuje błąd podczas zapisywania regionu podczas mapowania. Powinno nadal zezwalać na rm i zastępować. Problem polega na tym, że każdy, kto ma dostęp do pliku do odczytu, może go odwzorować i zablokować zapis, co spowoduje otwarcie lokalnego otworu DoS. (Rozważmy /etc/utmp. Pojawiła się propozycja, aby użyć bit wykonania uprawnień, aby to naprawić.)
Nie zamierzamy się podoba, ale jest trywialny łatka na jądro, które przywróci MAP_DENYWRITE funkcjonalności. Linux wciąż ma tę funkcję, po prostu usuwa bit w przypadku mmap(2). Trzeba to załatać w kodzie, który jest zduplikowany w architekturze, dla ia32 Wierzę, że plik jest arch/x86/ia32/sys_ia32.c.
asmlinkage long sys32_mmap2(unsigned long addr, unsigned long len,
unsigned long prot, unsigned long flags,
unsigned long fd, unsigned long pgoff)
{
struct mm_struct *mm = current->mm;
unsigned long error;
struct file *file = NULL;
flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE); // fix this line to not clear MAP_DENYWRITE
To powinno być OK, o ile nie ma żadnych złośliwych lokalnych użytkowników z poświadczeniami. To nie jest zdalne DoS, tylko lokalne.
To się zgadza. –