PLD CVS: SPECS misiek

[Tomasz Kłoczko]

On Sat, 10 Jul 1999, Arkadiusz Miśkiewicz wrote:

> [piątek, 09 lipiec 1999], Tomasz Kłoczko napisał(a):
> 
> > Tutaj zostało zmienione:
> > 
> > -%attr(750,root,bin) %dir /etc/tcpd
> > -%attr(640,root,bin) %config %verify(not md5 mtime size) /etc/tcpd/hosts.*
> > +%attr(751,root,bin) %dir /etc/tcpd
> > +%attr(644,root,bin) %config %verify(not md5 mtime size) /etc/tcpd/hosts.*
> > 
> > Przypuszczam dlaczego .. qmail albo coś innego co jest linkowane z
> > libwrap :>
> wszystko co z inetd chodzi z euidem != root i egid != bin, a korzystające z tcpd
> nie będzie mogło zaglądać do konfigów ... (tzn tcpd nie będzie wtedy mógł zajżeć)!!
> bo %attr(755,root,root) %{_sbindir}/*
> 
[..]
> > Da się zrealizować 2) bo jezeli nie to będziemy musizli się jednak zgodzić
> > na 1) ?
> w tej chwili sądzę, że nie da się zrobić tego :) 

A z jakim egid chodzi proces odbierajacy połączenia w qmailu i czy nie
może to być bin ?

Z innej beczki.
Przyglądam sie właśnie rlinetd i dochodzę do wniosku, że możnaby spróbować
wywalić inetd na zbity pysk. Co na to inni ?

Jeżeli odpowiedź był by w okolicach aprobaty to należałoby się wziąć ławą
za przerabianie pakietów z serwisami chodzącymi via inet srv tak żeby to
zrobić w maksymanie krótkim czasie (wcześniej uzgadniając jeszcze
potrzebne szczegóły proceduralne, o których wszyscy wykonujący
dostosowanie powinni wiedzieć .. o ile takowe będą). To znaczy dorobić
odpowiednie pliki które beda wlatywać do /etc/inetd.d/. Jeżeli byśmy
zrobili przejście nie ostre to znaczy sie w rlinetd wstawili "Provides:
inetd" to wszystko miałoby szansę w miarę głatko się pzreślizgać gdyż i
tak dotychczaswe serwisy via inet nie rejestrowały się w inetd.conf. Tak
czy inaczej rlinetd wymagałby jeszcze małych poprawek.

Czy ktoś tego używa wogóle już i jeżeli tak to czy mógłby się podzielić
obserwacjami i szansami wykonania takiej wolty bez skręcenia sobie karku ?

W każdym bąć razie rlinetd wydaje się o tyle dobry, że jest przeźroczysty
od strony tcpd .. znaczysię można go dalej stosować i tutaj przynajmniej
nie byłoby wyrwy w funkcjonalności całości (z g2s czy tcp serverem było tu
gorzej). Dodatkowo zapełnia ładne międzymordzie do tego żeby robić
chrootowane serwisy przy w zasadzie zerowym wysiłku. Po za tym zapewnia
modularny opis serwisów (via katalog, a nie pojedynczy plik konf.

W cron.dayly co najwyżej możnaby dla bezpieczpieczeństwa wstawić skrypt
sprzwdzający czy nie ma tam jakiś lewych plików nie zarejestrowanych w
bazie rpm-a i raportujący wszelkie obce elementa gdzie trzeba.

Co do jeszcze plików opisujących serwisy to wydają się one na tyle proste 
i uniwersalne, że mogłyby służyć za wzorcowy opis obsługiwanych serwisów w
razie gdyby komuś przyśniło się w przyszłości przejście na inny inet srv
(co byłoby możliwe przy zachodzniu nieostrych zależności polegających na
wy,maganiu czegoś cio by się nazywało inetd). W takim wypadku dla
zapewnienia back compat trzebaby jeszcze post factum wspomnianych
przeróbek w poszczególnymi pakietami z serwisami dorobić nieco obecnego
inetd żeby umiał sobie on start-up przerobić bazę rinetd na inetd.conf.

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*