L'autorizzazione alla condivisione Samba ha negato all'utente la scrittura del file ma viene comunque mostrata

Problema molto strano ...

Condivisione Samba sul telecomando:

[javaerpm]
    path = /u/abas/erpm/java
    force user = erpm
    guest ok = yes
    read only = no
    writeable = yes

Montare il comando su local usando root:

root@crunchbang:/mnt/abas# mount -t cifs -o username=guest,rw,exec,auto //10.0.0.2/javaerpm ./javaerpm

Root può leggere / scrivere / cd senza alcun problema:

root@crunchbang:/mnt/abas# cd javaerpm
root@crunchbang:/mnt/abas/javaerpm# touch test
root@crunchbang:/mnt/abas/javaerpm# ll
total 1
-rw-r--r--  1  501 users   0 Sep 24 09:55 test
root@crunchbang:/mnt/abas/javaerpm# rm test

Ma se passo a un utente normale e faccio la stessa cosa ottengo questo:

shawn@crunchbang:/mnt/abas/javaerpm$ touch test
touch: cannot touch `test': Permission denied

Posso lle posso vedere che ha scritto il file comunque:

shawn@crunchbang:/mnt/abas/javaerpm$ ll
total 1
-rw-r--r--  1  501 users   0 Sep 24 09:55 test

Non posso nemmeno rmavere problemi:

shawn@crunchbang:/mnt/abas/javaerpm$ rm test
shawn@crunchbang:/mnt/abas/javaerpm$

Ho provato diverse opzioni di montaggio. uid=501non cambia nulla. nounixHo provato ma poi non funziona affatto e non vedo nulla usando l'utente root o shawn.

_{Nota: sto solo indovinando qui, non sono un guru della samba.}

Samba / CIFS, almeno nel modo in cui lo stai utilizzando qui, non riproduce le credenziali tra il server e il client. A causa della force userdirettiva sul server, tutte le operazioni vengono eseguite come utente erpmsul server. Tuttavia, poiché sia ​​il client che il server eseguono un sistema unix, hanno negoziato automaticamente le estensioni POSIX CIFS . Ciò fa sembrare che le autorizzazioni unix funzionino fino a un certo punto, ma solo per quanto consentito dal server, e ti sei imbattuto in un caso in cui ciò che rivendicano le autorizzazioni unix e ciò che il server consente differiscono.

Noterai che tutti i file vengono visualizzati come ID utente 501. Questo è il loro uid sul server.

Quando si tenta di creare o rimuovere un file, ciò richiede l'autorizzazione di scrittura nella directory. Tutti gli accessi sono mappati a un singolo utente sul server, quindi l'autorizzazione in scrittura si riduce alla erpmpossibilità di scrivere su quella directory sul server. La risposta è si.

Quando si esegue touch, crea il file e quindi cambia il tempo di modifica. La modifica del tempo di modifica di un file richiede la proprietà e questo è testato dal codice del file system generico, sul lato client.

Se esegui strace touch test, noterai che quindi la openchiamata (che crea il file ) ha esito positivo, quindi la utimeschiamata (o meglio su Linux la utimensatchiamata di sistema) non riesce a impostare i tempi.

Questo è in realtà un po 'strano perché utimes dovrebbe avere successo, dal momento touchche lo chiama con un argomento NULL (che significa "imposta il timestamp sull'ora corrente"), e questo dovrebbe essere consentito a qualsiasi chiamante che può scrivere sul file, e non solo al proprietario come impostare un timestamp arbitrario. Ho il sospetto che utimensatstia effettivamente eseguendo un controllo basato sulle autorizzazioni e che determini che le autorizzazioni dicono che non puoi scrivere su quel file, anche se il filesystem consentirebbe un'operazione di scrittura indipendentemente dalle autorizzazioni effettive.

Il vantaggio principale delle estensioni POSIX CIFS quando il lato server è in esecuzione con le autorizzazioni di un utente non root è di trasferire il bit eseguibile e possibilmente raggruppare la proprietà. Potrebbe essere meno confuso se si associa la proprietà dell'utente a un singolo utente lato client con l' forceuidopzione mount.