Jak uzyskać pełną kontrolę nad umask / PAM / uprawnieniami?

// Zaktualizowano 8 lutego - Najważniejsze problemy w skrócie:

• Jak umaskować katalogi inaczej niż pliki?
• Jak umaskować na kopiowaniu / wklejaniu Nautilus?
• Jak ustawić Umask dla SSHFS?

NASZA SYTUACJA

Kilka osób z naszej firmy loguje się na serwer i przesyła pliki. Wszystkie muszą mieć możliwość przesyłania i zastępowania tych samych plików. Mają różne nazwy użytkowników, ale wszystkie należą do tej samej grupy. Jest to jednak serwer internetowy, więc „inni” użytkownicy powinni (ogólnie) mieć dostęp tylko do odczytu. Chcę więc mieć te standardowe uprawnienia:

pliki: 664
katalogi: 771

Moim celem jest, aby wszyscy użytkownicy nie musieli martwić się o uprawnienia. Serwer powinien być skonfigurowany w taki sposób, aby uprawnienia te dotyczyły wszystkich plików i katalogów, nowo utworzonych, skopiowanych lub nadpisanych. Tylko wtedy, gdy potrzebujemy specjalnych uprawnień, zmienilibyśmy to ręcznie.

Przesyłamy pliki na serwer przez SFTP-ing w Nautilusie, przez zamontowanie serwera za pomocą sshfs i dostęp do niego w Nautilusie, jakby to był folder lokalny, oraz przez SCP-ing w wierszu poleceń. Dotyczy to w zasadzie naszej sytuacji i tego, co chcemy zrobić.

Teraz przeczytałem wiele rzeczy o pięknej funkcjonalności umask. Z tego, co rozumiem, umask (wraz z PAM) powinien pozwolić mi robić dokładnie to, co chcę: ustawić standardowe uprawnienia dla nowych plików i katalogów. Jednak po wielu godzinach czytania i próbach i błędach nadal nie działam. Otrzymuję wiele nieoczekiwanych wyników. Naprawdę lubię dobrze rozumieć umask i mam wiele pytań bez odpowiedzi. Zamieszczę poniższe pytania wraz z moimi ustaleniami i wyjaśnieniem moich prób, które doprowadziły do ​​tych pytań. Biorąc pod uwagę, że wiele rzeczy wydaje się iść nie tak, myślę, że robię kilka rzeczy źle. Dlatego jest wiele pytań.

UWAGA: Używam Ubuntu 9.10 i dlatego nie mogę zmienić sshd_config, aby ustawić umask dla serwera SFTP. Zainstalowany SSH OpenSSH_5.1p1 Debian-6ubuntu2 <wymagany OpenSSH 5.4p1. Oto pytania.

1. CZY POTRZEBUJĘ PONOWNIE URUCHOMIĆ ZMIANY PAM, ABY SKUTECZNIE?

Zacznijmy od tego. W grę wchodziło tak wiele plików i nie byłem w stanie dowiedzieć się, co robi, a co nie wpływa na rzeczy, również dlatego, że nie wiedziałem, czy muszę ponownie uruchomić cały system, aby zmiany PAM zaczęły obowiązywać. Zrobiłem to, nie widząc oczekiwanych rezultatów, ale czy to naprawdę konieczne? Czy mogę po prostu wylogować się z serwera i zalogować ponownie, czy nowe zasady PAM powinny być skuteczne? Czy jest jakiś program „PAM” do przeładowania?

2. CZY JEST JEDEN JEDEN PLIK, ABY ZMIENIĆ WPŁYW NA WSZYSTKICH UŻYTKOWNIKÓW NA WSZYSTKIE SESJE?

Skończyło się na WIELU plikach, kiedy czytałem WIELE różnych rzeczy. Skończyłem ustawiać umask w następujących plikach:

~/.profile -> umask=0002
~/.bashrc -> umask=0002
/etc/profile -> umask=0002
/etc/pam.d/common-session -> umask=0002
/etc/pam.d/sshd -> umask=0002
/etc/pam.d/login -> umask=0002

Chcę, aby ta zmiana dotyczyła wszystkich użytkowników, więc jakaś zmiana w całym systemie byłaby najlepsza. Czy można to osiągnąć?

3. CZY WSZYSTKO, TO UMASK, TO DZIAŁA?

Po zmianie umask na 0002 w każdym możliwym miejscu uruchamiam testy.

------------ SCP -----------

TEST 1:

scp testfile (which has 777 permissions for testing purposes) server:/home/
testfile                                      100%    4     0.0KB/s   00:00   

Sprawdźmy uprawnienia:

user@server:/home$ ls -l
total 4
-rwx--x--x 1 user uploaders 4 2011-02-05 17:59 testfile (711)

AKTUALIZACJA: naprawione przez ustawienie TYLKO umask w pam.d / common-session (patrz komentarze)

--------- SSH ------------

TEST 2:

ssh server
user@server:/home$ touch anotherfile
user@server:/home$ ls -l
total 4
-rw-rw-r-- 1 user uploaders 0 2011-02-05 18:03 anotherfile (664)

-------- SFTP -----------

Nautilus: sftp: // server / home /

Skopiuj i wklej nowy plik z klienta na serwer (777 na kliencie)

TEST 3:

user@server:/home$ ls -l
total 4
-rwxrwxrwx 1 user uploaders 3 2011-02-05 18:05 newfile (777)

Utwórz nowy plik za pomocą Nautilus. Sprawdź uprawnienia do plików w terminalu:

TEST 4:

user@server:/home$ ls -l
total 4
-rw------- 1 user uploaders    0 2011-02-05 18:06 newfile (600)

Mam na myśli ... Co się tu właśnie stało ?! My powinniśmy dostać 644 za każdym razem. Zamiast tego dostaję 711, 777, 600, a potem 644. A 644 jest osiągane tylko podczas tworzenia nowego, pustego pliku przez SSH, co jest najmniej prawdopodobnym scenariuszem.

Pytam więc, czy w końcu umask / pam działa?

AKTUALIZACJA: naprawiono test 4 WYŁĄCZNIE ustawiając umask w pam.d / common-session (patrz komentarze)

4. CO TO OZNACZA DLA UMASK SSHFS?

Czasami montujemy serwer lokalnie, używając sshfs. Bardzo przydatne. Ale znowu mamy problemy z uprawnieniami.

Oto jak montujemy:

sshfs -o idmap=user -o umask=0113 user@server:/home/ /mnt

UWAGA: używamy umask = 113, ponieważ najwyraźniej sshfs zaczyna się od 777 zamiast 666, więc z 113 otrzymujemy 664, co jest pożądanym uprawnieniem do pliku.

Ale teraz dzieje się tak, że widzimy wszystkie pliki i katalogi tak, jakby były 664. Przeglądamy w Nautilusie do / mnt i:

• Kliknij prawym przyciskiem myszy -> Nowy plik (nowy plik) --- TEST 5
• Kliknij prawym przyciskiem myszy -> Nowy folder (nowy folder) --- TEST 6
• Skopiuj i wklej plik 777 z naszego lokalnego klienta --- TEST 7

Sprawdźmy więc wiersz poleceń:

user@client:/mnt$ ls -l
total 8
-rw-rw-r-- 1 user 1007    3 Feb  5 18:05 copyfile (664)
-rw-rw-r-- 1 user 1007    0 Feb  5 18:15 newfile (664)
drw-rw-r-- 1 user 1007 4096 Feb  5 18:15 newfolder (664)

Ale hej, sprawdźmy ten sam folder po stronie serwera:

user@server:/home$ ls -l
total 8
-rwxrwxrwx 1 user uploaders    3 2011-02-05 18:05 copyfile (777)
-rw------- 1 user uploaders    0 2011-02-05 18:15 newfile (600)
drwx--x--x 2 user uploaders 4096 2011-02-05 18:15 newfolder (711)

Co?! Uprawnienia do plików REAL są bardzo różne od tego, co widzimy w Nautilusie. Czy to umask na sshfs tworzy po prostu „filtr” pokazujący nierealne uprawnienia do plików? Próbowałem otworzyć plik od innego użytkownika, ale z tej samej grupy, która miała prawdziwe 600 uprawnień, ale 644 „fałszywych” uprawnień i nadal nie mogłem tego odczytać, więc po co ten filtr?

5. UMASK JEST WSZYSTKO O PLIKACH. ALE CO Z DIRECTORIES?

Z moich testów wynika, że ​​stosowany umask również w jakiś sposób wpływa na uprawnienia do katalogu. Chcę jednak, aby moje pliki to 664 (002), a moje katalogi to 771 (006). Czy to możliwe, aby mieć inny umask dla katalogów?

6. PERHAPS UMASK / PAM JEST NAPRAWDĘ CHŁODNY, ALE UBUNTU JEST TYLKO BŁĘDNY?

Z jednej strony czytałem tematy osób, które odniosły sukces w PAM / UMASK i Ubuntu. Z drugiej strony znalazłem wiele starszych i nowszych błędów dotyczących umask / PAM / fuse na Ubuntu:

• https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/241198
• https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/239792
• https://bugs.launchpad.net/ubuntu/+source/pam/+bug/253096
• https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/549172
• http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314796

Nie wiem już, w co wierzyć. Czy powinienem się poddać? Czy ACL rozwiąże wszystkie moje problemy? Czy mam znowu problemy z używaniem Ubuntu?

Jedno słowo ostrożności przy tworzeniu kopii zapasowych przy użyciu tar. Dystrybucje Red Hat / Centos obsługują acls w programie tar, ale Ubuntu nie obsługuje acls podczas tworzenia kopii zapasowej. Oznacza to, że wszystkie pliki acls zostaną utracone podczas tworzenia kopii zapasowej.

Jestem bardzo chętny do aktualizacji do Ubuntu 10.04, jeśli to też rozwiązałoby moje problemy, ale najpierw chcę zrozumieć, co się dzieje.

Wiele rzeczy mogło się tu dziać.

Pierwsze przemyślenia:

• tak, pam.d zmiany zaczynają obowiązywać natychmiast
• /etc/pam.d/common-session to najlepsze miejsce, aby ustawić wartość domyślną umask
• każde pam.d umask zostanie zastąpione przez dowolny wpis w .bashrc,
  ale .bashrczostanie odczytane tylko w pewnych okolicznościach (interaktywna powłoka bez logowania)
• testfile (711) jest bardzo dziwne
  • jak jest /homezamontowany i czy korzystasz z list ACL?
    (np. co robić ls -ld /homei getfacl /homedrukować?)
  • nie testfileistnieje, zanim zrobił kopię, bo scpnie zmieni uprawnienia do pliku, który już istnieje (chyba użyć -pflagi)
• Nautilus jest znany z tego, że tworzy pliki w inny sposób, nie jestem pewien, dlaczego i jakie są reguły
• umask=0113 prawdopodobnie spowoduje problemy
• czy serwer i klient mają ten sam system operacyjny?
  na przykład, jeśli klient ma włączone listy ACL lub Cygwin, zachowanie może być inne
• najlepszym sposobem na wymuszenie rozsądnych uprawnień jest użycie domyślnych list ACL, właśnie dlatego, jak odkryłeś, użytkownik umaskmoże zastąpić w .bashrci .bash_profile.

Aktualizacja:

• umask=0113 bo sshfs jest zły.
  1. Spróbuj zamontować bez określania umask
  2. Utwórz nowy plik w punkcie instalacji za pomocą touch.
  3. Powinieneś zobaczyć, że dostaje tylko np. -rw-r--r--Bez xbitów
  4. Przez maskowanie xbitów możesz uszkodzić katalogi,
     a kompilatory mogą nie być w stanie poprawnie utworzyć plików wykonywalnych

Obejście:

Jeśli nie możemy wymyślić nic lepszego, możesz użyć famlub gaminobserwować tworzenie nowych plików i naprawić uprawnienia do nich, a nawet po prostu skrypt, który uruchamia się okresowo i ustawia uprawnienia do wszystkich plików.

To nie jest związane z PAM / umask, ale może ci się przydać.

Jeśli ustawisz katalog, wszystkie pliki i katalogi w nim utworzone zostaną automatycznie przypisane do jego grupy.

root@ricarda ~ # mkdir hello      
root@ricarda ~ # chown :users hello 
root@ricarda ~ # chmod g+s hello
root@ricarda ~ # ls -l |grep hello 
drwxr-sr-x. 2 root users  4096 Feb  7 04:05 hello
root@ricarda ~ # touch hello/some_file
root@ricarda ~ # mkdir hello/some_dir
root@ricarda ~ # ls -l hello/       
total 4
drwxr-sr-x. 2 root users 4096 Feb  7 04:16 some_dir
-rw-r--r--. 1 root users    0 Feb  7 04:06 some_file

Przeczytaj także to rozwiązanie: Jak ustawić strukturę uprawnień dla wielu użytkowników edytujących wiele witryn w / var / www na Ubuntu 9.10?

Listy ACL powinny działać dobrze.

Ustaw domyślną listę ACL dla wszystkich folderów dla grupy, która zostanie następnie odziedziczona przez wszystkie przyszłe pliki i katalogi.

Coś jak setfacl -m d:g:uploaders:rwxpowinno działać.

Aby naprawić istniejące uprawnienia:

find /shared/folder -type d -exec setfacl -m d:g:uploaders:rwx {} \;
find /shared/folder -type f -exec setfacl -m g:uploaders:rw {} \;

Wygląda na to, że jeśli podczas kopiowania pliku ustawiono opcję „zachowaj”, domyślna lista ACL nie działa. W takim przypadku mogę jedynie zasugerować uruchomienie komend find w cron lub monitorowanie systemu plików pod kątem zmian.