Zmuszanie właściciela do utworzonych plików i folderów

Mam katalog, który zawiera dane współużytkowane przez wielu użytkowników. Dostęp do tego katalogu i wszystkiego pod nim będzie kontrolowany przez grupę katalogu, która zostanie dodana do danych użytkowników. Jako taki utworzyłem folder „lepka grupa” chmod g+s. Katalog będzie zawierał strukturę drzewa z katalogami i plikami, przy czym całkowita liczba plików może wynosić kilka milionów. Pliki będą dość małe, nie przewiduję niczego większego niż 50 MB.

Mój problem polega na tym, że właścicielem pliku lub katalogu nadal jest użytkownik, który go utworzył. Jako taki, nawet jeśli powinienem usunąć tego użytkownika z grupy dostępu, nie usunęłbym całkowicie jego dostępu.

Więc:

Czy są inne opcje, za którymi tęskniłem za zapewnieniem, że wszystkie pliki i podkatalogi mają tego samego właściciela?

Spodziewam się, że mogę okresowo przeglądać cały katalog z cron-job, ale to wydaje mi się nieefektywne w przypadku tego, co zasadniczo jest poleceniem jednorazowego pliku.

Znalazłem przykład użycia INotify, ale wydaje mi się, że wymaga dużej konserwacji, ponieważ wymaga skryptowania.

Nie byłem w stanie dowiedzieć się, czy ACL może mi pomóc w wymuszonej własności.

Czy jest na to mądrzejszy sposób?

Chcę mieć katalog, który można udostępniać, dodając grupę do użytkownika. Wszystko, co zostanie utworzone w tym katalogu, dziedziczy schemat uprawnień po rodzicu. Jeśli istnieje lepszy sposób niż to, co próbuję, jestem cały w uszach.

Ustawienie domyślnego właściciela na „automatycznie” wymagałoby setuidzachowania katalogu setgid. Jednak chociaż można to skonfigurować we FreeBSD, inne systemy UNIX i Linux po prostu ignorują u+s. W twoim przypadku może być jednak inne rozwiązanie.

Chcę mieć katalog, który można udostępniać, dodając grupę do użytkownika. Wszystko, co zostanie utworzone w tym katalogu, dziedziczy schemat uprawnień po rodzicu. Jeśli istnieje lepszy sposób niż to, co próbuję, jestem cały w uszach.

Zasadniczo z tego, co widzę, chcesz kontrolować dostęp do katalogu za pomocą mechanizmu grup. Nie wymaga to jednak ograniczenia uprawnień w całej strukturze katalogów. W rzeczywistości --xbit wykonania katalogu może być dokładnie tym, czego potrzebujesz. Dam ci przykład. Przy założeniu, że...

• Grupą kontrolującą dostęp do group_dirkatalogu jest ourgroup.
• ourgroupDostęp mają tylko osoby w grupie group_dir.
• user1i user2należą do ourgroup.
• Domyślnym umask jest 0022.

... rozważ następującą konfigurację:

drwxrws---    root:ourgroup   |- group_dir/
drwxr-sr-x    user1:ourgroup  |---- group_dir/user1_submission/
drwxr-sr-x    user2:ourgroup  |---- group_dir/user2_submission/
-rw-r--r--    user2:ourgroup  |-------- group_dir/user2_submission/README

^{Załóżmy, że każdy element został stworzony przez jego właściciela.}

Teraz w tej konfiguracji:

• Wszystkie katalogi mogą być przeglądane przez wszystkich ourgroup. Każdy z grupy może tworzyć, przenosić i usuwać pliki w dowolnym miejscu w środku group_dir(ale nie głębiej).
• Każdy, kto nie jest w ourgroupśrodku, zostanie zablokowany group_diri dlatego nie będzie mógł manipulować niczym pod nim. Na przykład user3(który nie jest członkiem ourgroup) nie może czytać group_dir/user2_submission/README(nawet jeśli ma r--uprawnienia do samego pliku).

Jednak w tym przypadku jest mały problem: z powodu typowego umask elementy tworzone przez użytkowników nie mogą być modyfikowane przez innych członków grupy. W tym miejscu pojawiają się listy ACL. Ustawiając domyślne uprawnienia, upewnisz się, że wszystko jest w porządku pomimo wartości umask:

$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/

To połączenie ustawia:

• Domyślne rw(x)uprawnienia właściciela.
• Domyślne rw(x)uprawnienia dla grupy.
• Brak domyślnych uprawnień dla innych. Pamiętaj, że skoro inni igroup_dir tak nie mają dostępu, tak naprawdę nie ma znaczenia, jakie są ich uprawnienia poniżej.

Teraz, jeśli utworzę element jako user2:

$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw----    user2:ourgroup    group_dir/user2_submission/AUTHORS

Po wprowadzeniu tej listy ACL możemy spróbować odbudować naszą poprzednią strukturę:

drwxrws---+    root:ourgroup   |- group_dir/
drwxrws---+    user1:ourgroup  |---- group_dir/user1_submission/
drwxrws---+    user2:ourgroup  |---- group_dir/user2_submission/
-rw-rw----+    user2:ourgroup  |-------- group_dir/user2_submission/README

^{Tutaj ponownie każdy element jest tworzony przez jego właściciela.}

Dodatkowo, jeśli chcesz dać nieco więcej mocy / bezpieczeństwa osobom korzystającym z katalogu, możesz rozważyć trochę lepkiej. Zapobiegnie to na przykład user1usunięciu user2_submission(ponieważ ma -w-na to pozwolenie group_dir):

$ chmod +t group_dir/

Teraz, jeśli user1spróbuje usunąć user2katalog, dostanie piękny Operation not permitted. Należy jednak pamiętać, że chociaż zapobiega to modyfikacjom struktury katalogów group_dir, pliki i katalogi poniżej są nadal dostępne:

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ cat /dev/null > user2_submission/README

user1@host $ file user2_submission/README
user2_submission/README: empty (uh-oh)

Inną rzeczą, którą należy wziąć pod uwagę, jest to, że używane przez nas listy ACL konfigurują domyślne uprawnienia. W związku z tym właściciel elementu może zmienić uprawnienia z nim związane. Na przykład user2może doskonale działać ...

$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R

... dlatego jego pełny katalog zgłoszeń jest niedostępny dla wszystkich członków grupy.

Ponieważ jednak początkowo chcesz udzielić pełnego rwsdostępu każdemu w grupie, zakładam, że ufasz tym użytkownikom i nie spodziewałbyś się po nich zbyt wielu złośliwych operacji.

Jest na to mądrzejszy sposób. Wykorzystuje kombinację set-gid i domyślnych acls. Oczywiście będziesz potrzebować systemu plików obsługującego acl. Załóżmy, że katalog, który chcesz udostępnić, znajduje się /var/grpdiri że członkowie grupy sharingpowinni mieć do niego dostęp.

chown root:sharing /var/grpdir
chmod 2770 /var/grpdir #other can't read or traverse into the directory, set-gid is set
setfacl -d -m u::rwX,g::rwX,o::0 /var/grpdir

Domyślne listy ACL są dziedziczone przez podkatalogi utworzone w katalogu z domyślnymi listami ACL. Oznacza to, że każdy utworzony plik /var/grpdirbędzie miał ustawioną grupę sharingna bit setgid katalogu. Dodatkowo odziedziczy domyślny acls, który zastąpi domyślne założenia stylu linux, ponieważ nie określiliśmy list ACL dla określonych użytkowników lub grup. Oznacza to, że wszystkie pliki zostaną utworzone z prawem własności <user>:sharingi uprawnieniami rw-rw----. Katalogi będą takie same, z tym że będą miały również własne domyślne listy ACL ustawione na takie same jak ich parent ( /var/grpdir) i oczywiście mają ustawione bity wykonywalne dla użytkownika i grupy. Jeśli usuniesz użytkownika z sharinggrupy, nie będzie on mógł uzyskać dostępu do katalogu (ani żadnych plików w nim zawartych, nawet jeśli są ich właścicielami).

W przeciwieństwie do okresowego korygowania uprawnień za pomocą usługi współdziałania, uprawnienia są zawsze zsynchronizowane, ponieważ są one aktualizowane atomowo o nowo utworzone pliki i katalogi. To rozwiązanie jest lekkie; żadne demony nie są potrzebne i nie ma skoków do IO podczas korekty uprawnień za jednym zamachem.

Nie znam żadnego dobrego sposobu na zrobienie tego. Technicznie najczystszym sposobem byłby system plików FUSE, który to robi. Oczywiście dużo pracy, jeśli nikt tego jeszcze nie zrobił.

Alternatywy:

1. Użyj samby. samba ma force userparametr. Możesz wyeksportować katalog lokalnie i zamontować go lokalnie. Nie sprawia, że ​​dostęp jest szybszy, ale może być akceptowalny, ponieważ w grę wchodzi tylko sieć zwrotna.

2. Użyj systemu plików innego niż Linux, takiego jak FAT32. Musi to być skonfigurowane dla określonego użytkownika, aby go zamontować. Uprawnienia dostępu muszą być obsługiwane przez katalog nadrzędny.

Nie słyszałem o żadnym sposobie automatycznej zmiany własności pliku, tak aby właściciel pliku został zmieniony po przeniesieniu pliku do określonego katalogu. Najbliższą rzeczą jest lepka wersja, ale wygląda na to, że wskazałeś, że własność grupy nie wystarczy, rzeczywista własność użytkownika musi się zmienić.

W takim przypadku myślę, że najlepszym rozwiązaniem jest praca crona z flagą chown -R, jak wspomniała Pandya. Umieść go na cronie, aby uruchamiał się co minutę lub co pięć minut.

Jeśli możesz wyjaśnić, w jaki sposób użytkownicy korzystają z tego, może być lepsze rozwiązanie.

ACL może pomóc ci uzyskać lepszą kontrolę nad ziarnem, kto może robić, co nie, automatycznie nie zmieni faktycznej własności pliku. Myślę, że musisz uzyskać bardziej szczegółowy widok i ocenić / przeprojektować swoje rozwiązanie na tej podstawie.

Możesz użyć narzędzi inotify i napisać prosty skrypt bash, jak poniżej. Inotify będzie pilnować sieci katalogu i zrobi coś, gdy zdarzenie takie jak tworzenie katalogu będzie miało miejsce w katalogu sieci. Istnieje wiele wydarzeń. Możesz google go lub może zajrzeć na tę stronę

while inotifywait -m -e CREATE web; do echo "A new directory has been created"; done