zagrodzki: kernel.spec

[Tomasz Kłoczko]

On Mon, 21 Jan 2002, Artur Frysiak wrote:
[..]
> > Tak jeszcze aptropo tego co można zmienić. Usunałbym restrykcje dot 
> > ptrace. Gdyby nie to że używam płyt RW straciłbym juz kilka płyt. Kawałek 
> > z dmesg:
> > 
> > Security: signal 11 (write addr 0xbf7fff6c) sent to cdrecord[13328], UID 0, EUID 0, parent cdrecord[13327], UID 0, EUID 0, by cdrecord[13328], UID 0, EUID 0, parent cdrecord[13327], UID 0, EUID 0
> > 
> > nie wiedże w tej chwili aż takie j duzej potzreby żeby bawić się w
> > "okładanie" ptrace i to tym bardziej że w obecnej formie nie mozan tego w
> > żaden sposób wyłaczyć. Mówiac inaczje jest to wybitnie upierdliwa rzecz o
> > ile bawi się na takim hoscie w developmen.
> 
> Nie bardzo rozumien gdzie tu jest związek Sig11 z blokadą ptrace ?

Związek jest taki że gdzieś jest coś w tym patchu co powoduje że cdrecord 
dostaje becki. To czego jest to wina (cdrecorda czy poprawek w kernelu) to 
już inna bajka i masz rację .. o ile patch blokuje poprawnie ptrace() to 
nie powyże nie powinno mieć miejsca. Niemniej bez przejrzenia tego co 
własniwie powoduje wywalenie się cdrecord cieżko bezie to zlokalizowac.
Wydaje mi się że patch na ptrace powinien o ile to mozliwe zrzucać do 
sysloga informacje umożliwiające zlokalizowanie pinktu w kodzie programu 
który wykonał niedozwolną operację. Potencjalnie o ile blokada ptrace() w 
podobmnym stylu ale w module byłaby poprawna mogłaby się przyczynić od 
wychwycenia pewnej ilosci błędów w programach.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*