Re: problemi di permessi su shares nfs
Dario scrisse in data 06/03/2012 20:41:
> Il problema comunque non era banale nell'individuarlo, ne ho
> approfittato per "informarmi" meglio (non si finisce mai di imparare).
in effetti devo dire che ho avuto un bel cxxo averlo trovato in un thread...
> La RFC 5531 [1] (Remote Procedure Call Protocol Specification Version
> 2), (sottolineo "NFS versione 2") all'appendica A riporta quanto segue:
>
> > Appendix A: System Authentication
> >
> > The client may wish to identify itself, for example, as it is
> > identified on a UNIX(tm) system. The flavor of the client
> credential
> > is "AUTH_SYS". The opaque data constituting the credential encodes
> > the following structure:
> >
> > struct authsys_parms {
> > unsigned int stamp;
> > string machinename<255>;
> > unsigned int uid;
> > unsigned int gid;
> > unsigned int gids<16>;
> > };
> >
> > The "stamp" is an arbitrary ID that the caller machine may generate.
> > The "machinename" is the name of the caller's machine (like
> > "krypton"). The "uid" is the caller's effective user ID. The "gid"
> > is the caller's effective group ID. "gids" are a counted array of
> > groups that contain the caller as a member. The verifier
> > accompanying the credential should have "AUTH_NONE" flavor value
> > (defined above). Note that this credential is only unique within a
> > particular domain of machine names, uids, and gids.
>
> Quindi il limite dei gruppi massimo è 16 proprio come previsto da RFC.
> (aca l'array gids<16>)
>
> Pur usando le ACL non si risolverebbe il problema, perché alla fine
> ritorniamo sempre ad NFC con il limite dei 16 gruppi....
>
> Ho trovato molto interessante questa lettura [2] e questa [3],
> dove vengono dati suggerimenti su quali soluzioni scegliere.
>
> Non nascondo il desiderio che qualcuno più addentrato mi spieghi di
> più al riguardo :-), e magari mi dia lumi sul perché quel dì la
> Sun Microsystems decise questo limite, invece di un array quanto meno
> più grande (magari 255).
mi associo.
> Vero è che in un sistema avere un utente associato alla quasi
> maggioranza dei gruppi presenti ....non è cosa :-)
non so, in realtà faccio un po' fatica a capire bene dalla
documentazione quali permessi siano associati ad un gruppo di lavoro. Ad
esempio il gruppo cdrom:
This group can be used locally to give a set of users access to a CD-ROM
drive.
Quindi se voglio poter utilizzare un cdrom (quindi anche masterizzare)
devo essere inserito nel gruppo cdrom o basta essere in plugdev?
Oppure floppy (si, il mio pc ha anche il floppy anche se in effetti non
lo uso più), camera o il gruppo video: secondo voi a quali gruppi debba
necessariamente appartenere un utente perché possa usare tutte le
periferiche appiccicate al sistema?
Il mio utente comunque appartiene ad una decina di gruppi: cdrom, fax,
floppy, audio, video, plugdev, camera, powerdev, fuse e in più c'è il
gruppo personale dell'utente.
Quando lo lego ad un dominio samba l'accesso ad alcuni servizi sono
legati anch'essi all'appartenenza ad un gruppo così di base fra domain
users e altri servizi se ne aggiungono altri 4/5. Ora poi se l'utente
appartiene a qualche gruppo di lavoro ecco che arrivare a 16 gruppi non
è poi così difficile.
> Vero anche che il caso che hai segnalato Paolo, mi risulta un pò
> arzigolato :-D [ma forse dovuto ad un ambiente misto Windows/Linux]
>
> Scusa se la share riguarda la cartella http (desumo contenente
> il sito Intranet e quindi il webserver) .. perché condividerla in quel
> modo? [sempre se posso chiedere :-)]
perché è condivisa sia con samba (anche gli utenti windows vogliono
accedere alla root del webserver) che con nfs per gli utenti linux.
Certo gli utenti linux possono usare anche samba ma per principio io
preferisco nfs.
> Se si tratta di modificare un file di configurazione del portale
> interno, non era più semplice gestire la cosa da applicativo web ?
> magari con uno scriptino ad'uopo? Piuttosto che legarsi ad
> username-gruppi Samba+NFS solo per gestire i permessi di un singolo file?
> Dove per errore potrei pure cancellare quel file creando un disastro
> sugli script che ne fanno l'inclusione?
se si lavorasse da soli si: lavori in locale poi aggiorni il server
remoto. Quello è un server di sviluppo e più utenti accedono ai files e
li modificano... non lavoriamo con sistemi di versioning ma direttamente
sul server di sviluppo. Ci sono sicuramente altri modi ma non vedo
perché cambiare.
Ciao e grazie
Piviul
Reply to: