L'autorisation de partage Samba a refusé à l'utilisateur d'écrire le fichier mais affiche toujours

Problème très étrange ...

Partage Samba à distance:

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

Commande de montage sur local en utilisant root:

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

Root peut lire / écrire / cd sans aucun problème:

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

Mais si je passe à un utilisateur régulier et fais la même chose, j'obtiens ceci:

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

Je peux llet je peux voir qu'il a écrit le fichier de toute façon:

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

Je peux même rmpas de problème:

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

J'ai essayé différentes options de montage. uid=501ne change rien. nounixJ'ai essayé mais ça ne marche pas du tout et je ne vois rien en utilisant l'utilisateur root ou shawn.

_{Remarque: je devine juste ici, je ne suis pas un gourou de la samba.}

Samba / CIFS, du moins de la façon dont vous l'utilisez ici, ne reproduit pas les informations d'identification entre le serveur et le client. En raison de la force userdirective sur le serveur, toutes les opérations sont effectuées en tant qu'utilisateur erpmsur le serveur. Cependant, étant donné que le client et le serveur exécutent tous deux un système Unix, ils ont négocié automatiquement les extensions CIFS POSIX . Cela fait que les autorisations Unix semblent fonctionner jusqu'à un certain point, mais uniquement dans la mesure où le serveur le permet, et vous avez rencontré un cas où ce que les autorisations Unix revendiquent et ce que le serveur autorise diffèrent.

Vous remarquerez que tous les fichiers apparaissent sous l'ID utilisateur 501. C'est leur UID sur le serveur.

Lorsque vous essayez de créer ou de supprimer un fichier, cela nécessite une autorisation d'écriture sur le répertoire. Tous les accès sont mappés à un seul utilisateur sur le serveur, donc l'autorisation d'écriture se résume à savoir si erpmest autorisé à écrire dans ce répertoire sur le serveur. La réponse est oui.

Lorsque vous exécutez touch, il crée le fichier, puis modifie son heure de modification. La modification de l'heure de modification d'un fichier nécessite la propriété, ce qui est testé par le code du système de fichiers générique, côté client.

Si vous exécutez strace touch test, vous remarquerez que l' openappel (qui crée le fichier) réussit, puis l' utimesappel (ou plutôt sur Linux l' utimensatappel système) ne parvient pas à définir les heures.

C'est en fait un peu bizarre car cela utimes devrait réussir, car touchil l'appelle avec un argument NULL (ce qui signifie «définir l'horodatage à l'heure actuelle»), et cela est censé être autorisé pour tout appelant qui peut écrire dans le fichier, et pas seulement au propriétaire, comme définir un horodatage arbitraire. Je soupçonne que cela utimensatfait en fait une vérification basée sur les autorisations et détermine que les autorisations disent que vous ne pouvez pas écrire dans ce fichier, même si le système de fichiers autoriserait une opération d'écriture indépendamment des autorisations réelles.

Le principal avantage des extensions CIFS POSIX lorsque le côté serveur s'exécute avec les autorisations d'un utilisateur non root est de reporter le bit exécutable et éventuellement la propriété du groupe. Il peut être moins déroutant si vous mappez la propriété de l'utilisateur à un seul utilisateur côté client avec l' forceuidoption de montage.