ehhhh

Buonasera a tutti

io a casa ho una mini rete LAN (2 pc collegati direttamente) e volevo far si che in uno potessi visualizzare la partizione dell'altro....

assumendo che gli indirizzi che io abbia dato siano (visto che si tratta di una rete privata)
192.168.xx.10 per il pc A e
192.168.xx.20 per il pc B

ho provato ad usare il comando

(nel Pc A voglio vedere una partizione del Pc B)
mount 192.168.xx.20:/dev/hday /mnt/directory_z

mi restituisce un errore riguardo la libreria RPC

RPC port mapper failure unable to receive

che faccio???

Gabriele

attachment.htm (1.53 KB)

Gabriele Izzo wrote:

Buonasera a tutti

io a casa ho una mini rete LAN (2 pc collegati direttamente) e volevo
far si che in uno potessi visualizzare la partizione dell'altro....

assumendo che gli indirizzi che io abbia dato siano (visto che si
tratta di una rete privata)
192.168.xx.10 per il pc A e
192.168.xx.20 per il pc B

ho provato ad usare il comando

(nel Pc A voglio vedere una partizione del Pc B)
mount 192.168.xx.20:/dev/hday /mnt/directory_z

Aia, puoi fare il mount di una directory che e' messa nel file
/etc/exports del altro PC, p.e.

    mount -t nfs 192.168.1.20:/home /mnt/altrohome

mi restituisce un errore riguardo la libreria RPC

RPC port mapper failure unable to receive

Il portmaper e' attivo?

    /etc/rc.d/init.d/portmap status

Si? E nfs e nfslock? Se i servizi lavorono andiamo a vedere /etc/exports
C'e' qualcosa come

    /directory IP-altro-PC(rw, altri opzioni)

o

    /dir (ro, altro)

p.e.

    /home 192.168.1.10(rw,no_root_squash)

Guardi la man-page del file, trovi tanti consigli, anche di sicurezza!!

    man exports

Altro problema possibile. Esistono anche impostazioni di firewall di
default che chiudono i port necessari per nfs (qualche Red Hat)!

Ciao
Karl

Buonasera,

ringrazio Karl per le dritte.....

> RPC port mapper failure unable to receive

Il portmaper e' attivo?

    /etc/rc.d/init.d/portmap status

Si? E nfs e nfslock? Se i servizi lavorono andiamo a vedere /etc/exports
C'e' qualcosa come

    /directory IP-altro-PC(rw, altri opzioni)

effettivamente c'erano un paio di demoni disabilitati....
Comunque a parte questo adesso riesco ad installare la partizione ma non ho
i permessi per entrare.
Il problema è che la directoy i permessi ce li ha e nel file export ho messo
(rw) che immagino sia lettura scrittura....il tutto da super user.....boh???

Gabriele

Gabriele Izzo wrote:

Buonasera,

ringrazio Karl per le dritte.....

RPC port mapper failure unable to receive
     

Il portmaper e' attivo?

   /etc/rc.d/init.d/portmap status

Si? E nfs e nfslock? Se i servizi lavorono andiamo a vedere /etc/exports
C'e' qualcosa come

   /directory IP-altro-PC(rw, altri opzioni)

effettivamente c'erano un paio di demoni disabilitati....
Comunque a parte questo adesso riesco ad installare la partizione ma non ho
i permessi per entrare.

I permessi non vanno assegati al utente come va fatto con Samba, M$ o
Novell NetWare. NFS non usa un proprio sistema di permessi o di
autentificazione. I permessi sono legati al filesistem (i soliti rwx per
l'owner, il gruppo e per il mondo), manca il concetto di ACL (almeno
fin ora in un installazione standard). L'autentificazione e' quella
fatta dal client e questo e' problema piu' grave di NFS. Se qualcuno si
mette in rete e dice di essere l'utente con una certa UID lo e', il
server non chiede altro. Se sulla macchina A lavori come pippo con l'UID
501 e il GID 501 e vuoi usare und directory sulla macchina B devi creare
l'utente con UID e/o GID 501 e dare i permessi in maniera giusta
(chmod), o dai i permessi a tutto il mondo come e' d'uso sul altro
sistema :wink:

Have fun
Karl

Salve lista,

premetto di non aver mai usato NFS. Ho sempre solo letto mails e sentito
critiche. Sulla mailing list focus-linux(a)securityfocus.com e' abbena
passato un thread sulla tematica.

NFSv3 come spiegato da Karl non supporta ACLs.

Ci sono dei patch in giro. Ad esempio la RHEL ed altre dovrebbe
includerli. Grande svantaggio, le ACL-rules non sono standardizzate e
percio' non sono cross distro. Non parlando di altri sistemi ad esempio
Solaris.

Un altro workaround consiste nel usare un filesystem con ACL al di sotto
del NFS (ad esempio XFS). Funziona datoche NFS per ogni utente fa
partire un nuovo processo, coi diritti del utente connesso. I problemi
consitono nella divergenza dei diritti NFS e gli ACL. Ad esempio
l'utente connesso vede il diritto di scrittura, ma non riesce a
scrivere, datoche l'ACL (che lui non vede) non lo consente.

NFSv4 dovrebbe supportare Kerberos, ma e' ancora molto alpha.

Visto tutto questo, mi chiedo perche' non usare Samba. Che vantaggi
porta NFS?

Happy hacking!
Patrick

p.s. Ho cambiato il soggetto della e-mail in qualcosa di piu' sensato.

Patrick Ohnewein wrote:

Visto tutto questo, mi chiedo perche' non usare Samba. Che vantaggi
porta NFS?

1. Puoi usarlo come root-filesystem per sistemi diskless. Per samba non
penso che funzioni, perche' al momento del boot non c'e' ancora nessun
utente che puo' fare il login. E poi non so se e' supportato dal kernel.

2. Lo uso per distribuire i directory degli utenti su due server. I
server hanna una seconda scheda di rete e sono connessi con un cavo
cross over

3. Per cluster e' facile utilizzare NFS per utilizzare un filesystem shared

4. E' il sistema classico e ancora piu' semplice da configurare di
samba, ma questo non dovrebbe essere una scusa per usarlo.

5. C'e' tanta documentazione per NFS negli HOWTO e su tanti libri
GNU/Linux. Filesystems come AFS, Coda, DCE/DFS, Intermezzo e altri
ancora sono molto meno supportati dalla communita'.

Bye, Karl

Ciao Karl,

vedo che per fare una rete con terminali, NFS ha i suoi vantaggi.

La questione della sicurezza e' pero' molto preoccupante. Se solo una
macchina in rete e' compromessa, tutti i dati diventano accessibili.

Oppure ci sono rimedi al problema?

Happy hacking!
Patrick

Patrick Ohnewein wrote:

Ciao Karl,

vedo che per fare una rete con terminali, NFS ha i suoi vantaggi.

La questione della sicurezza e' pero' molto preoccupante. Se solo una
macchina in rete e' compromessa, tutti i dati diventano accessibili.

Oppure ci sono rimedi al problema?

Con NFSv3 sotto GNU/Linux pochi. LTSP fa l'export del root-filesystem in
solo lettura (ro). Per un NFS tra server puoi fare una rete fisica fra
questi e puoi utilizzare anche il rw. Sun ha qualcosa che si chiama
SecureNFS con caratteristiche avanzate, ma non e' free. La strada da
prendere sono le alternative come AFS, Coda, ... Il problema e' che NFS
ha fatto tanta storia ed arriva da un epoca senza ACL, senza NetWare,
senza NTFS e tanto altro che oggi e' standard. Non esisteva un
portatile, neanche und Personal Computer che si pottevano collegare in
rete e cosi il problema non esisteva. La rete era composta dai server e
i terminali.

Oggi nessuno prova a far girare DOS con interfaccia grafica e
funzionalita' TCP/IP in una rete e si aspetta di avere sicurezza. NFS ha
certe proprieta' ed e' sbagliato aspettarsi qualcosa che NFS non e'. NFS
e' un veccio mostro come DOS, telnet, Netscape 4, lynx, C/C++, sendmail,
il programma mail, tftp, gopher o anche altro. Per certe situazioni
vanno bene, ma non per tutte.

Ciao
Karl

PS: Forse anche TeX e/o LaTeX sono dei vecchi mostri che non vanno bene
per tutti :wink:

Con NFSv3 sotto GNU/Linux pochi. LTSP fa l'export del root-filesystem in
solo lettura (ro).

Questo per quanto ho capito previene di poter accedere in scrittura con
UID 0, ma su una macchina collegata in rete posso sempre crearmi gli
utenti (500-???) locali, poi fare un su - <UTENTE> e in fine fare il
mount del NFS share, che sarebbe riservato solo ad un certo utente.
Oppure non funziona?

Oggi nessuno prova a far girare DOS con interfaccia grafica e
funzionalita' TCP/IP in una rete e si aspetta di avere sicurezza. NFS ha
certe proprieta' ed e' sbagliato aspettarsi qualcosa che NFS non e'. NFS
e' un veccio mostro come DOS, telnet, Netscape 4, lynx, C/C++, sendmail,
il programma mail, tftp, gopher o anche altro. Per certe situazioni
vanno bene, ma non per tutte.

Concordo.

Tu che alternativa suggerisci. Se uno mette su una rete e vuole creare
degli share, cosa potrebbe usare.

Se usa Samba, per quanto ho capito, ha restrizioni nei diritti sui file
al di sotto degli share. Praticamente tutte le manipulazioni sotto uno
share ricevono un solo utente.gruppe una create mask per i file ed una
per le directory e poi basta. Un chmod o chown non sono concepiti.

Altri FS con ACL sono ancora giovani o cene sono alcuni gia' maturi?

Happy hacking!
Patrick

ext3 + posix acl

ext3 + posix acl

Ach so. Hast du Links zu mehr Infos?

Kann man damit Freigaben machen?

Happy hacking!
Patrick

Patrick Ohnewein wrote:

Con NFSv3 sotto GNU/Linux pochi. LTSP fa l'export del root-filesystem
in solo lettura (ro).

Questo per quanto ho capito previene di poter accedere in scrittura
con UID 0, ma su una macchina collegata in rete posso sempre crearmi
gli utenti (500-???) locali, poi fare un su - <UTENTE> e in fine
fare il mount del NFS share, che sarebbe riservato solo ad un certo
utente. Oppure non funziona?

Su un export in solo lettura nessuno puo' modificare qualcosa, ne un
utente, ne root. Per quanto riguarda il mount, quello non e' fatto per
un solo utente! Un mount NFS e' definito in /etc/exports e li non si
parla di utenti. Un concetto diverso e' quello del mapping degli utenti
e gruppi per evitare che certi utenti (root!) possono utilizzare la
directory con i propri UID e GID. 'root_squash' fa il mapping di UID 0
sul UID di nobody. Cosi l'utente root non puo' utilizzare quel share
come root, ma soltanto come nobody.

    man exports

Ciao Karl,

Su un export in solo lettura nessuno puo' modificare qualcosa, ne un
utente, ne root. Per quanto riguarda il mount, quello non e' fatto per
un solo utente! Un mount NFS e' definito in /etc/exports e li non si
parla di utenti. Un concetto diverso e' quello del mapping degli utenti
e gruppi per evitare che certi utenti (root!) possono utilizzare la
directory con i propri UID e GID. 'root_squash' fa il mapping di UID 0
sul UID di nobody. Cosi l'utente root non puo' utilizzare quel share
come root, ma soltanto come nobody.

hai raggione, avevo confuso le due cose. Dopo aver visto gli esempi nel
man, penso di aver capito. Ti chiedo conferma ai miei sospetti.

EXAMPLE
        # sample /etc/exports file
        / master(rw) trusty(rw,no_root_squash)
        /projects proj*.local.domain(rw)
        /usr *.local.domain(ro) @trusted(rw)
        /home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
        /pub (ro,insecure,all_squash)

E' vero, che se setto il nome della mia macchina su pc100, posso fare il
mount della home directory di joe?

La combinazione delle opzioni all_squash e anan?id penso che facciano in
modo, che ogni azione venga fatta come utente.gruppo sul server 150.100.
In questo caso non riconosco vantaggi nei confronti del'uso di uno samba
share.

Se e' vero che cambiando il nome della macchina si possa fare il mount
degli share, ancora peggio sarebbe se nello configurazione sopra
riportata qualcuno settasse il nome su master o magari trusty.

L'unica via di scampo mi sembra essere la soluzione da te usata, cioe'
usare una rete fisicamente distaccata. O esisterebbero anche altre?

Scusa se ti chiedo i buchi nello stomaco (traduzione del detto tedesco
;)), la tematica mi interessa molto, perche' spesso vengo chiesto sul
come fare share in reti. Solo non avvendo altre esperienze al di fuori
che con Samba non mi e' mai stato possibile dare una risposta concreta.

Vista la storia e l'uso massiccio di NFS, mi sembra importante capire i
vantaggi e svantaggi. Poi vorrei anche valutare l'uso dei nuovi FS con ACL.

Happy hacking!
Patrick

Patrick Ohnewein wrote:

Ciao Karl,

Su un export in solo lettura nessuno puo' modificare qualcosa, ne un
utente, ne root. Per quanto riguarda il mount, quello non e' fatto
per un solo utente! Un mount NFS e' definito in /etc/exports e li non
si parla di utenti. Un concetto diverso e' quello del mapping degli
utenti e gruppi per evitare che certi utenti (root!) possono
utilizzare la directory con i propri UID e GID. 'root_squash' fa il
mapping di UID 0 sul UID di nobody. Cosi l'utente root non puo'
utilizzare quel share come root, ma soltanto come nobody.

hai raggione, avevo confuso le due cose. Dopo aver visto gli esempi
nel man, penso di aver capito. Ti chiedo conferma ai miei sospetti.

EXAMPLE
       # sample /etc/exports file
       / master(rw) trusty(rw,no_root_squash)
       /projects proj*.local.domain(rw)
       /usr *.local.domain(ro) @trusted(rw)
       /home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
       /pub (ro,insecure,all_squash)

E' vero, che se setto il nome della mia macchina su pc100, posso fare
il mount della home directory di joe?

Non pensa che basti???, devi essere pc100 anche per il server NFS. O
nella sua /etc/hosts o nel naming usato dal server.

La combinazione delle opzioni all_squash e anan?id penso che facciano
in modo, che ogni azione venga fatta come utente.gruppo sul server
150.100. In questo caso non riconosco vantaggi nei confronti del'uso
di uno samba share.

Non ci sono se vuoi condividera dati. Forse NFS e' piu' stabile al
momento che il server non e' raggiungibile per qualche tempo. Quando il
server ritorna funziona subito tutto, senza che il client deve rifare il
mount. Questo e' importante se e' un share tra macchine di un sistema
distribuito o cluster.

Se e' vero che cambiando il nome della macchina si possa fare il mount
degli share, ancora peggio sarebbe se nello configurazione sopra
riportata qualcuno settasse il nome su master o magari trusty.

Cambiare il nome, be. Ma chi ha accesso alle rete puo' sempre collegarsi
con l'IP di master o trusty e allora hai il problema!

L'unica via di scampo mi sembra essere la soluzione da te usata, cioe'
usare una rete fisicamente distaccata. O esisterebbero anche altre?

Senza ulteriori servizi no. Poi fare quel che fa Endian per la scuola
professionale Enrico Mattei a Bressanone. Usano i filtri a livello
iptables e danno certi servizi soltano alla macchina con l'indirizzo MAC
giusto. Cosi porti la sicurezza dall'indirizzo IP all'indirizzo MAC. Ma
poi arriva quello che in qualche modo ha rubato gli indirizzi MAC e si
assegna un indirizzo alla propria scheda. La sicurezza con NFS non c'e',
perche' mancha l'autentificazione sul lato server. Soltanto con
filesystem di reti avanzati come AFS, Coda, ... lo puoi evitare. Non so
se Samba o ncpfs possono essere alternative a questi.

Scusa se ti chiedo i buchi nello stomaco (traduzione del detto tedesco
;)), la tematica mi interessa molto, perche' spesso vengo chiesto sul
come fare share in reti. Solo non avvendo altre esperienze al di fuori
che con Samba non mi e' mai stato possibile dare una risposta concreta.

Con Samba hai tutto per fare i share. Non e' un filesystem UNIX e cosi
non puoi (o forsi si, non so) usarlo per installare sistemi per il
diskless per sistemi con terminali o il clustering, per sistemi
distrubuiti o altro. Per scambiarsi dati Samba va benissimo. Oltre Samba
c'e' anche Mars e ncpfs che usano i protocolli e le funzionalita' di un
semplice Novell NetWare :wink: Ma questo non ho mai usato, Max lo conosce.

Vista la storia e l'uso massiccio di NFS, mi sembra importante capire
i vantaggi e svantaggi. Poi vorrei anche valutare l'uso dei nuovi FS
con ACL.

Come filesystem locale ACL da dei grandi vantaggi, ma se metti su NFS
hai gli stessi casini. Non capisco perche' un ACL locale possa risolvere
il problema dell'autentificazione remota. OK, con Kerberos. I rawhide
della RedHat di primavera, cioe' le beta prima della Red Hat 9, avevano
l'ACL, ma poi hanno perso il coraggio e lo hanno tolto.

C'e' un bel progetto:

    http://www.grsecurity.net/
    http://www.grsecurity.net/features.php
    http://www.grsecurity.net/papers.php

E su linuxwiki ci sono dei link:

    http://linuxwiki.de/ACL

Forse c'e' qualcuno sulla lista che ha piu' esperienza. Sarebbe un bel
workshop: "Network Filesystems" :wink:

Ciao
Karl

hallo

> ext3 + posix acl

Ach so. Hast du Links zu mehr Infos?
Kann man damit Freigaben machen?

naja.. habs vor einigen jahren mal gelesen dass das recht gut geht.
selbst probiert hab ichs nicht.
posix acl ist ein kernel patch.. ist im 2.6 aber inkludiert. (hat ein
österreicher geschrieben)

dadurch dass ext2 drunter liegt, ists relativ gut getestet wuerde ich
sagen.

freigaben? die kann man mit samba dann machen, die posix acls sind nur
eine erweiterung des bestehenden rechtesystems.. sie erlauben dann bei
jeder datei/verzeichnis genau festzulegen welcher user, welche gruppe
darauf wie zugreifen darf. und zwar nicht wie bisher ueblich (1 user, 1
gruppe, others) sondern eben acl-maessig, (n user,..usw)

ich kann mir vorstellen dass die administration dabei ziemlich wild und
unuebersichtlich wird.. aber so kann man rechte vergeben wie unter einem
nt-share.

peter