bandwidth per uid

[T 6]

Polecicie coś, co potrafi liczyć ilość przesłanych danych przez dany uid w systemie i zrzucać to np. do pliku? Ew. jakieś bardziej gotowe rozwiązania, które pozwolą wdrożyć limit GB/mies. per uid? Z góry mówię, że nie chodzi mi o rozwiązania zintegrowane z konkretnymi aplikacjami, np. apache, bo takie znam i nie są dla mnie wystarczające.

 

Z góry dzięki za pomoc

[Gość adamszendzielorz]

Polecicie coś, co potrafi liczyć ilość przesłanych danych przez dany uid w systemie

 

W fazie eksperymentalnej ale jest:

 

CONFIG_IP_NF_MATCH_OWNER:

 

Packet owner matching allows you to match locally-generated packets based on who created them: the user, group, process or session.

 

 

Networking options --->

IP: Netfilter Configuration --->

Owner match support (EXPERIMENTAL) (NEW)

 

pozdr.

[gb 12]

Adamie CONFIG_IP_NF_MATCH_OWNER dziala na podstawie uid/gid processu (ogolnie rzecz ujmujac), pytajacemu zapewne chodzilo o zliczanie na podstawie uid pliku w systemie. W celu zliczania ruchu w ten sposob musialby kazdy plik serwerowac jako user tego pliku, czyli korzystac ze zmiany usera dla kazdej sesji z serwerem http.

 

Osobiscie nie znam rozwiazania "z pudelka", ktore umie to zrobic ale chetnie poznam :-) My to rozwiazujemy poprzez autorskie patche na apacha (http server).

[Gość adamszendzielorz]

Adamie CONFIG_IP_NF_MATCH_OWNER dziala na podstawie uid/gid processu (ogolnie rzecz ujmujac), pytajacemu zapewne chodzilo o zliczanie na podstawie uid pliku w systemie. W celu zliczania ruchu w ten sposob musialby kazdy plik serwerowac jako user tego pliku, czyli korzystac ze zmiany usera dla kazdej sesji z serwerem http.

 

Z http to sobie moze z logow wyciagnac ile danych dana wirtualka (w domysle UID) wygenerowala - cala reszte wyciagnie uzywajac wlasnie CONFIG_IP_NF_MATCH_OWNER - czyli ruch z roznego rodzaju np. serwerow ktore stawiaja userzy, sesji shellowych etc

pozdr.

[T 6]

Adamie CONFIG_IP_NF_MATCH_OWNER dziala na podstawie uid/gid processu (ogolnie rzecz ujmujac), pytajacemu zapewne chodzilo o zliczanie na podstawie uid pliku w systemie. W celu zliczania ruchu w ten sposob musialby kazdy plik serwerowac jako user tego pliku, czyli korzystac ze zmiany usera dla kazdej sesji z serwerem http.

 

Osobiscie nie znam rozwiazania "z pudelka", ktore umie to zrobic ale chetnie poznam :-) My to rozwiazujemy poprzez autorskie patche na apacha (http server).

 

No, wiadomo, że na podstawie uid procesu, właśnie o to pytałem. Ogólnie uważam odpalanie httpd na produkcyjnym serwerze pod jakimś jednym uidem za nieporozumienie -- bezpieczeństwo!

[Gość adamszendzielorz]

No, wiadomo, że na podstawie uid procesu, właśnie o to pytałem. Ogólnie uważam odpalanie httpd na produkcyjnym serwerze pod jakimś jednym uidem za nieporozumienie -- bezpieczeństwo!

 

Tzn mowa oczywiscie o tresci dynamicznej (CGI) ?

Bo statycznie to jasne, ze lepiej odpalac wszystko pod wspolnym UIDem Aczkolwiek przy zchrootowanym srodowisku nawet odpalanie CGI (php i reszta) z prawami wspolnego usera moze byc bezpieczne (teoretycznie nawet bardziej, bo nie ma nigdzie potencjalnie niebezpiecznych suidow:)

pozdr.

[gb 12]

Tylko jesli CGI odpalasz w bezpiecznym srodowisku jako jeden user to zaczynaja sie problemy z prawami do plikow toworzynych dynamicznie przez te procesy.

[Gość adamszendzielorz]

Tylko jesli CGI odpalasz w bezpiecznym srodowisku jako jeden user to zaczynaja sie problemy z prawami do plikow toworzynych dynamicznie przez te procesy.

 

To fakt, dlatego zapoznalem sie i lubie kolege suexeca ;-)

pozdr.

[gb 12]

Przepisywales pod swoje potrzeby czy uzywasz prosto z pudelka ?

[Gość adamszendzielorz]

Przepisywales pod swoje potrzeby czy uzywasz prosto z pudelka ?

 

Jest dosyc sporo zmienione ale nawet z pudelka jest przeciez bezpieczny

A dopisywanie czegos tylko potencjalnie zwieksza niebezpieczenstwo

 

Glowne moje zmiany to obsluga limitow (cpu time / mem / nr proc) i obsluga dwoch rodzai PHP - 4 i 5 jednoczesnie (w zaleznosci co tam sobie user wybierze). W standardzie tego brak

pozdr.

[gb 12]

Jesli ktos nie wie co zmienia to napewno zwieksza niebezpieczenstwo ;-) Z tego co pamietam to nawet jest taki "disclaimer" w README :-)

 

"nr proc" ? ilosc procesow generowanych przez uid'a ?

[Gość adamszendzielorz]

"nr proc" ? ilosc procesow generowanych przez uid'a ?

 

Tak

pozdr.

[gb 12]

Ciekawi mnie jak to rozwiazaliscie, jesli oczywiscie nie jest to tajemnica. Standardowe limity nakladaja jedynie "cap" na ilosc procesow forkowanych przez parenta. Mysmy to rozwiazali poprzez bezposredni patch na kernel.

[Gość adamszendzielorz]

Ciekawi mnie jak to rozwiazaliscie, jesli oczywiscie nie jest to tajemnica. Standardowe limity nakladaja jedynie "cap" na ilosc procesow forkowanych przez parenta. Mysmy to rozwiazali poprzez bezposredni patch na kernel.

 

Zwyczajnie i wyjatkowo prosto w suexec.c:

 

struct rlimit *mylimit = (struct rlimit*) malloc(sizeof(struct rlimit));

[...]

#define NPROC 20

[...]

mylimit->rlim_cur = NPROC; mylimit->rlim_max = NPROC; setrlimit(RLIMIT_NPROC, mylimit);

[...]

 

^^ opz, phpbb zmienia znak wiekszosci na & gt ;

 

Dziala wysmienicie

pozdr.

 

Wysłany 2005-09-05, 12:27:

 

Zapomnialem dodac, ze potrzebny jest jeszcze patch openwalla na kernel i wkompilowana opcja:

 

Enforce RLIMIT_NPROC on execve(2)

 

pozdr.