Zezwolenie na udostępnianie Samby odmówiło zapisu pliku użytkownika, ale nadal się wyświetla

Bardzo dziwny problem ...

Udostępnianie Samby na pilocie:

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

Polecenie zamontowania na komputerze lokalnym przy użyciu roota:

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

Root może w ogóle odczytać / zapisać / cd:

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

Ale jeśli przejdę do zwykłego użytkownika i zrobię to samo, otrzymam to:

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

Widzę lli widzę, że i tak zapisał plik:

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

Nie mogę nawet rmmieć problemu:

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

Próbowałem różnych opcji montażu. uid=501nic nie zmienia. Próbowałem, nounixale potem w ogóle nie działa i nie widzę nic za pomocą użytkownika root lub shawn.

_{Uwaga: zgaduję tutaj, nie jestem guru samby.}

Samba / CIFS, przynajmniej sposób, w jaki tutaj go używasz, nie odtwarza poświadczeń między serwerem a klientem. Ze względu na force userdyrektywę na serwerze wszystkie operacje są wykonywane jako użytkownik erpmna serwerze. Ponieważ jednak zarówno klient, jak i serwer działają w systemie uniksowym, automatycznie negocjowały rozszerzenia CIFS POSIX . To sprawia, że ​​uprawnienia unix wydają się działać do pewnego momentu, ale tylko na tyle, na ile pozwala na to serwer, i natrafiłeś na przypadek, w którym roszczenia dotyczące uprawnień unixowych i co serwer pozwala.

Zauważysz, że wszystkie pliki są wyświetlane jako ID użytkownika 501. To jest ich identyfikator użytkownika na serwerze.

Podczas próby utworzenia lub usunięcia pliku wymaga to pozwolenia na zapis w katalogu. Cały dostęp jest mapowany na jednego użytkownika na serwerze, więc uprawnienie do zapisu sprowadza się do tego, czy erpmwolno pisać w tym katalogu na serwerze. Odpowiedź brzmi tak.

Po uruchomieniu touchtworzy plik, a następnie zmienia czas modyfikacji. Zmiana czasu modyfikacji pliku wymaga własności i jest to testowane przez ogólny kod systemu plików po stronie klienta.

Jeśli uruchomisz strace touch test, zauważysz, że następnie openwywołanie (które tworzy plik ) zakończy się powodzeniem, a następnie utimeswywołanie (a raczej utimensatwywołanie systemowe w systemie Linux ) nie ustawi czasu.

To jest naprawdę trochę dziwne, ponieważ utimes powinno się powieść, ponieważ touchwywołuje je z argumentem NULL (co oznacza „ustaw znacznik czasu na bieżący czas”), i powinno to być dozwolone dla każdego dzwoniącego, który może zapisać do pliku, i nie tylko do właściciela, jak ustawienie dowolnego znacznika czasu. Podejrzewam, że w utimensatrzeczywistości wykonuje kontrolę opartą na uprawnieniach i ustalenie, że uprawnienia mówią, że nie można zapisywać do tego pliku, nawet jeśli system plików zezwala na operację zapisu niezależnie od faktycznych uprawnień.

Główną zaletą rozszerzeń CIFS POSIX, gdy po stronie serwera działa z uprawnieniami użytkownika innego niż root, jest przeniesienie bitu wykonywalnego i ewentualnie własność grupy. Może to być mniej mylące, jeśli zamapujesz własność użytkownika na pojedynczego użytkownika po stronie klienta za pomocą forceuidopcji montowania.