Dnia niedziela, 30 stycznia 2005 12:32, Jakub Bogusz napisał: > A nie chodzi o to, że PaX zwraca EACCES przy próbie wywołania mprotect() > dla binarek, które właśnie wykonywalnego stosu sobie życzą? > (w starszym glibcu był dołączony taki hack ignorujący EACCES w takim > przypadku - ale to tylko ukrywanie problemu)
Dokładnie - pomyliłem się z tym EPERM. > > > Na wcześniejszym glibcu takich negatywnych efektów nie zaobserwowałem > > > (wszystko miało non-exec na stosie i restrykcje na mprotect()), a na > > > nowym po wyczyszczeniu tej fagi na wszystkich bibliotekach za pomocą > > > execstack wszystko pięknie hula. Proponuję więc, aby czyścić tą flagę > > > podczas budowania rpm'ów. > To po kiego trzymać PaX, jak nie chcesz go używać? Czy ja go wtedy nie używam? Wtedy glibc nie próbuje ustawić wykonywalnego stosu dla biblioteki, więc nie ma błędu przy ładowaniu binarki i dopóki nie zacznie ona wykonywać stosu wszystko działa. W przeciwnym wypadku trzeba by zdjąć restrykcje z mprotect() i pozwolić na wykonywanie stosu dla programów koszystających z tak "uszkodzonej" biblioteki. W tym przypadku błędu też nie będzie bo PaX zostanie po prostu wyłączony. _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
