tmpwatch i /home/users

[Tomasz Kłoczko]

On Sat, 21 Apr 2001, Grzegorz 'Dzikus' Sterniczuk wrote:

> On Sat, 21 Apr 2001 09:40:26 +0200 (CEST), you wrote:
> >IMHO lepiej jednak byłoby przerobić ten patch na wykrywacz podejrzanych
> >sytuacji. Mógłby być IMHO co najwyżej konfigurowalny (np. przez
> >procfs) czy dynamiczność ma być wąłczona czynie. jakby był wykrywacza to
> >to pozwalałoby na wychwytywanie programów które maja jeszcze błędy.
> >Błąd pozostaje błędem i to nawet jeżeli się go tylko przykryje tak że go
> >nie widać.
> 
> Oki ale rozwiązanie z `ln -s ///euid/700////tmps/!/ /tmp` wydaje się być
> imho bardzo ciekawe, gdyby do tego dorzucić jeszcze wykrywacz to mamy
> rozwiązane 99% problemów z /tmp race :)

W sumie coś takiego moznaby jednak zrobić poprostu ustawiająć $TMPDIR i
zakładajac odpoweiodni katalog (niezależnie czy byłoby to robione z
poziomu /etc/profile.d/tmpdir.{csh,sh} czy lokalnie i patch do kernela do
tego nie jest potrzebny. Wykrywać sytuacji podejrzanych .. o to co innego,
ale i to można załatwić inaczje znacznie skromniejszymi sirodkami nie
grzebiac w kernelu. Wystarczy napisać wrapper na kilka funkcji libc i
ładowanie libdetect_strage_tmp.so wrzucić do /etc/ld.so.preload. Czyli jak
sam widzisz patch do kernela to to i tak jest strzelanie z armaty do
wróbla lubteż jednak niezrozumienie pewnych innych włąsności systemu na
którym sie operuje. Teraz sobie przypomniałem ale zdaje się że chyba w
OpenBSD jest taki kawwałek shatred liba ładowany przez preload. Jest to o
tyle eleganckie że o ile ktoś tego nie chce mieć to nie będzie miał
(samego shared liba i modyfikację /etc/ld.so.preload można ładnie
zapaczkować).

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*