ftp, rc-inetd, tcpserver

[Tomasz Kłoczko]

On Mon, 18 Oct 1999, Grzegorz Stanislawski wrote:
[..]
> Kiedys bardzo mi sie podobal pwdb, ale teraz mysle ze bobrze ze nie jest
> rozwijany, poniewaz nie dodawal swoim istnieniem nic poza paroma
> zmarnowanymi taktami procesora i balaganem (choc mozy bylo by inaczej
> gdyby byl skonczony). Konfiguracja bazy danych z ktorej autoeyzowani bylu
> userzy rozkladala sie pomiedzy a /etc/nssswitch do /etc/pwdb.conf.

Swoją drogą czy nie mogłoby to być tylko nssswitch.conf ? Wydaje się to
dość logiczne, a wtedy moze miałoby i większy sens (?).

> PAM
> sobie (pwdb.conf) a glibc sobie (nssswitch) jakims rozwiazaniem do tego
> byl nsspwdb.so ale trzeba sie bylo postarac zeby go zdobyc i zainstalowac.
> Wracajac do PAMa. I tak nie uda sie uciec przed reczna konfiguracja
> pam.d/*. Bo skad, obojetnie jak inteligentny, skrypt ma wiedziec jaka
> polityke bezpieczenstwa przyjmie admin w stosunku do takich aplikacji jak
> chfn,chsh, rlogin, xauth czy zwyklego ftp albo nawet telneta.

Tyle, że w tym wypadku chodzi wyłacznie o modyfikacje sekwencji modułów
odpoweidajacych za dostarczanie informacji o użytkowanikach i zasobach ich
konta opisujących. To mi się wydaje, że nie musi dotykać polityki w tym
sensie w jakim to nadmieniałeś.

[..]
> > We wszelkiej automatyzacji chodzi nie tyle o wspomaganie osadzania np.
> > pakietu w środowisku co bardziej o odseparowanie w pewiem dobrze
> > wytestowany podprogram (moze być i w sh) który wykona _tylko_ to co
> > konieczne i w stu procentach powtarzalne przy okazji jakieś operacji np.
> > przejścia na trzymanie niektórych baz w LDAP.
> > 
> Zgadzam sie. Tymniemniej decyzja wyboru bazy z ktorej bedzie dokonywana
> autoryzacja powinna byc podjeta przez admina, co powinien on potwierdzic
> reczna zmiana w odpowiednich plikach konfiguracyjnych.

W sytuacji keidy mamy dualizm nsswitch.conf vis PAM[+PWDB]+moduły
dodatkowe do wyciagania informacji z konkretnych typów baz bardzo łatwo
doprowadzić do rozjechania całości. Także konserwacja juz choćby na etapie
konfigurowania systemu vanilla staje się niepotrzebnie bardziej
skomplikowana w momencie kiedy specyfikujesz wrecz pakietami (np. nss) z
jakich typów baz danch w systemie chciałbyć korzystać.
Tutaj chciałem namienić, że chciałbym wyróżnić moduły nss z glibc (nis,
nisplus i hesiod) do tego żeby wąłsnie tymi "punktami" takie sterowanie w
sposób jednoznaczny było możliwe.

[..]
> > Co powiesz na takie podejście Grasiek ?
> > 
> Podsumowujac.
> Zaden program instlacyjny czy sktypt nie moze wyreczyc admia w opracowaniu
> i wdrozeniu polityki bezpieczenstwa. Musi to zrobic sam, a skrypty moga mu
> jedynie pomoc w jej realizacji. IMHO jedyna pomoca na ktora tutaj moze
> liczyc admin to konwersja baz czy pomoc w zakladaniu kont (jeden skrypt
> adduser ktory bedzie zaipsywal dane tam gdzie trzeba. moze dalo by sie
> to zrobic za pomoca jakis pluginow). Proponowal bym sie skupic nad tym
> ostatnim.

Adduser .. o to też jest ważne (dobrze, że to wyartykułowałeś).

> Troche jest IMHO bez sensu ze ta dyskusja wyplynela przy okazji rc-inetd,
> ale lepiej niz wcale.

To są dość pokrewne tematy gdyż odnoszą się do pewnych "atomów"/składników
podstawowych, z których wszysko lepimy i w tym wybieraniu elementów do
uładanki łatwo pomylić coś elementarnego z czymś co takim elementem nie
jest. Pewne elementy tej układanki mogą IMHO inicjować pewne dalsze
zmiany. Na przykład instalacja pakietów NSS może modyfikować pliki
konfiguracyjne czy też (z konieczności obecnej formy PAM) także i pliki
/etc/pam.d/* umożliwiając także w dalszym etapie zainstalowanie innych
narzędzi jak choćby yp-tools których poprawne działanie jest uzależnione
od wcześniejszej modyfikacji plików odpowiedzialnych za to zeby pewne
informacje były brane także/wyłacznie z pewnych baz. W tym sensie i w tym
momencie tej dyskusji pakiety z modułąmi NSS mogą być inicjatorami takich
zmian, które co tu mówić w przypadku nsswitch.conf wykonać na pewno da się
w sposób powtrzalny i pewny, a pytanie tylko czy da sie to samo zrobić z
konfiguracja PAM (mi się wydaje, ze się da).

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*