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 ll
et 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 rm
pas de problème:
shawn@crunchbang:/mnt/abas/javaerpm$ rm test
shawn@crunchbang:/mnt/abas/javaerpm$
J'ai essayé différentes options de montage. uid=501
ne change rien. nounix
J'ai essayé mais ça ne marche pas du tout et je ne vois rien en utilisant l'utilisateur root ou shawn.
Réponses:
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 user
directive sur le serveur, toutes les opérations sont effectuées en tant qu'utilisateurerpm
sur 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
erpm
est 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'open
appel (qui crée le fichier) réussit, puis l'utimes
appel (ou plutôt sur Linux l'utimensat
appel système) ne parvient pas à définir les heures.C'est en fait un peu bizarre car cela
utimes
devrait réussir, cartouch
il 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 celautimensat
fait 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'
forceuid
option de montage.la source
username=guest,defaults,noperm
et cela a totalement résolu le problème. Je ne sais pas quelle réponse accepter sur celle-ci car ceusername=guest,defaults,noperm
n'est probablement pas la meilleure réponse et je n'ai tout simplement pas plus de temps pour essayer votre réponse. Merci encore!