Re: problemi di permessi su shares nfs
Il 06/03/2012 15:45, Paolo Sala ha scritto:
> dea scrisse in data 06/03/2012 14:35:
>> Riesci a risolvere con qualche workaround ?
>>
> beh, il più era trovare dove fosse il problema, ora in qualche modo farò.
>
> Mille grazie, poter esporre il problema spesso porta magicamente anche
> la possibilità di poterlo risolvere (o almeno affrontare).
>
> Piviul
Il problema comunque non era banale nell'individuarlo, ne ho
approfittato per "informarmi" meglio (non si finisce mai di imparare).
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).
Vero è che in un sistema avere un utente associato alla quasi
maggioranza dei gruppi presenti ....non è cosa :-)
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 :-)]
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?
:-) ho la tendenza alle cose semplici, forse sbaglio.
Dario
---link---
[1] http://tools.ietf.org/html/rfc5531
[2] https://xkyle.com/solving-the-nfs-16-group-limit-problem/
[3]
http://nfsworld.blogspot.com/2005/03/whats-deal-on-16-group-id-limitation.html
Reply to: