On 28 Nov 2001 at 10:10, Alessandro Forghieri wrote:
> Qualche tempo fa valeva il seguente principio:
> *LE SHADOW PASSWORD SONO FONDAMENTALMENTE INCOMPATIBILI CON NIS* (circa
> 1995)
> essenzialmente perche' NIS manca di un meccanismo di autenticazione
> affidabile per le macchine che vogliono fare un bind al server -
> inoltre, su una macchina "legata" (bound) a un server NIS ha il permesso
> di fare ypcat di una mappa quasiasi, che non va punto d'accordo col
> principio delle shadow password. Per questa ragione e' stato poi
> inventato NISPLUS.
>
> Come spiega questo riferimento:
> http://www.linuxdoc.org/LDP/nag2/x-087-2-nis.shadow.html
>
> la cosa e' ancora sostanzialmente vera.
>
> Questo e' il motivo per cui tra le varie mappe standard (hosts,
> services, networks, (ethers??), passwd, group, le mappe di automount..)
> shadow tradizionalmente non figurava.
>
> I sistemi con una libc nuova aggiungono qualche facilitazione per la
> *gestione*, ma non aggiustano il problema centrale.
Vediamo se ho capito:
Un client ancora non sa quali sono gli utenti validi perchè questi sono
sul server... quindi non può avere un accesso "autenticato" ma solo per
IP (che per la mia rete sarebbe sufficiente a garantire che macchina lo
ha fatto). Però ogni utente di un client può richiedere il file passwd
e crackarsi le password. Giusto?
Se è questo mi accontento... dunque posso/devo esportare anche shadow
right?
> > C) io non voglio le password in chiaro in giro per la mia rete ne
> > stockate in nessun file, come faccio a essere sicuro che
> > usa le shadow?
> Non saranno in chiaro (ne'lo sono mai state su U*X), ma non potrai usare
Perfetto. Più che altro le uso ma senza senso, visto che shadow è
accessibile solo a root ma così sarebbe accessibile a tutte le macchine
che possono accedere al server NIS, indipendentemente dall'utente.
> le shadow (vedi sopra). Se non ti va, devi passare a NIS+, o LDAP + TLS,
> o magari TACACS o RADIUS (per chi ha dei cisco...)
NIS+ non c'è il server per Linux.
LDAP non mi sembra vada altrettanto d'accordo con NFS.
> Per il resto delle tue domande ti consiglio "Managing NFS e NIS" di Hal
> Stern (O'Reilly) che e' vecchiotto, ma e' stato scritto da uno dei
> progettisti del sisstema. Inoltre NIS (senza +) e NFS (versione non ONC)
> sono stati sviluppati assai poco dall'epoca di questo libro.
Mi sono appena appropriato di Professional Linux Programming, Wrox
nella libreria in cui lavoro :) Non posso eccedere in espropri.
Comunque appena passo in magazzino una sbirciatina... visto che è in
stock :)
> Questo libro e un po' di pratica sul campo spnp bastati a persuadermi di
> non usare *mai* NIS se posso evitarlo.
Bhe la LAN è personale... non ho utenti che cercheranno di scipparmi la
PW di root da dentro. Il problema è fuori dal firewall. Supposto di
chiudere le porte dei servizi NIS all'esterno mi rimane sempre il
dubbio che con qualche stratagemma senza bucarmi completamente il
firewall riescano a convincere il server NIS a spedir fuori passwd.
Certo che NIS mi sembra molto più semplice da setuppare e maggiormente
integrato con gli altri servizi di quanto non mi paiano LDAP et Co.
Comunque dato per buono che sul server deve girare il client, che se
esporto shadow pace e amen ma almeno funziona, che se cambio i file su
cui viene costruito il DB NIS in maniera impropria il lavoro di cron
potrebbe avere un senso rimangono:
1) i famosi + su cui ho qualche _speranza_ di capire come funziona la
faccenda da solo
2) MERGE_PASSWD MERGE_GROUP (MINUID=0 e via...)
3) la questione PAM che credo sia risolta perchè non ci sono entries
pam_pwdb in /etc/pam.d anche se il setup è diverso da quello suggerito.
non vorrei chiudermi fuori dalla macchina da solo però.
Un _aiutino_, visto che prima di settimana prossima "Managing NFS e
NIS" non lo vedo?
Grazie
--
Salve
Ivan Sergio Borgonovo
http://www.webthatworks.it/
|