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.
źródło
chown -hR owner:group
?Odpowiedzi:
Ustawienie domyślnego właściciela na „automatycznie” wymagałoby
setuid
zachowania katalogusetgid
. 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.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
--x
bit wykonania katalogu może być dokładnie tym, czego potrzebujesz. Dam ci przykład. Przy założeniu, że...group_dir
katalogu jestourgroup
.ourgroup
Dostęp mają tylko osoby w grupiegroup_dir
.user1
iuser2
należą doourgroup
.... rozważ następującą konfigurację:
Załóżmy, że każdy element został stworzony przez jego właściciela.
Teraz w tej konfiguracji:
ourgroup
. Każdy z grupy może tworzyć, przenosić i usuwać pliki w dowolnym miejscu w środkugroup_dir
(ale nie głębiej).ourgroup
środku, zostanie zablokowanygroup_dir
i dlatego nie będzie mógł manipulować niczym pod nim. Na przykładuser3
(który nie jest członkiemourgroup
) nie może czytaćgroup_dir/user2_submission/README
(nawet jeśli mar--
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:
To połączenie ustawia:
rw(x)
uprawnienia właściciela.rw(x)
uprawnienia dla grupy.group_dir
tak nie mają dostępu, tak naprawdę nie ma znaczenia, jakie są ich uprawnienia poniżej.Teraz, jeśli utworzę element jako
user2
:Po wprowadzeniu tej listy ACL możemy spróbować odbudować naszą poprzednią strukturę:
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
user1
usunięciuuser2_submission
(ponieważ ma-w-
na to pozwoleniegroup_dir
):Teraz, jeśli
user1
spróbuje usunąćuser2
katalog, dostanie pięknyOperation not permitted
. Należy jednak pamiętać, że chociaż zapobiega to modyfikacjom struktury katalogówgroup_dir
, pliki i katalogi poniżej są nadal dostępne: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
user2
może doskonale działać ...... dlatego jego pełny katalog zgłoszeń jest niedostępny dla wszystkich członków grupy.
Ponieważ jednak początkowo chcesz udzielić pełnego
rws
dostę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.źródło
group_dir
w ogóle, bez względu na to, czy jest właścicielem pliku, czy nie. Jedynym prawdziwym „przywilejem” właściciela jest to, że może on zmienić uprawnienia do jego tworzenia (które szczegółowo opisałem w mojej odpowiedzi).group_dir
Katalog jest własnościąroot:ourgroup
z-rwxr-x---
, co oznacza, że tylko root i członkowieourgroup
mają do niej dostęp, to znaczy zrobić coś z plikami pod nią. Jeśli nie masz--x
uprawnień do katalogu, nie możesz uzyskać dostępu do pliku w nim zawartego , nawet jeśli masz uprawnienia do samego pliku.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/grpdir
i że członkowie grupysharing
powinni mieć do niego dostęp.Domyślne listy ACL są dziedziczone przez podkatalogi utworzone w katalogu z domyślnymi listami ACL. Oznacza to, że każdy utworzony plik
/var/grpdir
będzie miał ustawioną grupęsharing
na 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>:sharing
i uprawnieniamirw-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 zsharing
grupy, 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.
źródło
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:
Użyj samby. samba ma
force user
parametr. 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.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.
źródło
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.
źródło
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ę
źródło