Jeden plik chce należeć do dwóch użytkowników. W jaki sposób? Twarde linkowanie kończy się niepowodzeniem

Dwa programy setuid /usr/bin/bari /usr/bin/bazwspółdzielą jeden plik konfiguracyjny foo. Trybem pliku konfiguracyjnego jest 0640przechowywanie poufnych informacji. Biegnie jeden program, jak bar:bar(to jest, jak dla pręta, grupa bar ); drugi jak baz:baz. Zmiana użytkowników nie jest opcją, a nawet zmiana grup nie byłaby lepsza.

Chcę na stałe połączyć pojedynczy plik konfiguracyjny jako /etc/bar/fooi /etc/baz/foo. Nie udaje się to jednak, ponieważ plik, o ile wiem, musi należeć do root:barlub do root:baz.

Potencjalne rozwiązanie: Utwórz nową grupę, barbazktórej członkami są bari baz. Niech foonależy do root:barbaz.

To dla mnie wygląda na ciężkie rozwiązanie. Czy nie ma prostszego, prostszego sposobu udostępniania pliku konfiguracyjnego foomiędzy dwoma programami?

Na razie utrzymuję dwie identyczne kopie pliku. To działa, ale jest oczywiście błędne. Co by było właściwe?

Dla informacji: Mam niewielkie doświadczenie z grupami Unixowymi i żadną z setgid (2).

Możesz używać list ACL, aby plik mógł być odczytany przez osoby w obu grupach.

chgrp bar file
chmod 640 file
setfacl -m g:baz:r-- file

Teraz oboje bari bazgrup można odczytać pliku.

Na przykład, oto plik należący do bin: bin w trybie 640.

$ ls -l foo
-rw-r-----+ 1 bin bin 5 Aug 17 12:19 foo

Te +środki Tam jest zestaw ACL, więc rzućmy okiem na to.

$ getfacl foo
# file: foo
# owner: bin
# group: bin
user::rw-
group::r--
group:sweh:r--
mask::r--
other::---

Widzimy linię group:sweh:r--: oznacza to, że ludzie w grupie swehmogą ją przeczytać.

Hej, to ja!

$ id
uid=500(sweh) gid=500(sweh) groups=500(sweh)

I tak, mogę odczytać plik.

$ cat foo
data

Możesz ponownie rozważyć te stwierdzenia:

Potencjalne rozwiązanie: Utwórz nowy barbaz grupy, którego członkami są bari baz. Niech foonależy do root:barbaz.

To dla mnie wygląda na ciężkie rozwiązanie. Czy nie ma prostszego, prostszego sposobu udostępniania pliku konfiguracyjnego foomiędzy dwoma programami?

Dlaczego ciężko jest stworzyć nową grupę? Ma to następujące zalety w porównaniu z listami ACL:

• Chociaż sformułowałeś to jako hipotetyczne polecenie /usr/bin/bari /usr/bin/bazważne jest, aby te dwa programy mogły współdzielić plik konfiguracyjny. Sugeruje to, że programy są naturalnie powiązane. Utworzenie dla nich nowej grupy wydaje się opisywać relację, która faktycznie istnieje i powinna wyzwalać zachowanie (takie jak uprawnienia do odczytu wspólnego pliku konfiguracyjnego).
• Rozwiązanie tego problemu za pomocą grup jest przenośne dla każdego Uniksa, co oznacza, że ​​możesz polegać na tym samym mechanizmie, działającym dokładnie w ten sam sposób, na dowolnym systemie Unix lub podobnym do Uniksa. Listy ACL są znacznie bardziej złożone, a przenośność może stanowić problem.

Osobiście uważam, że listy ACL są tu ciężkim rozwiązaniem, a grupują jako prostszy, tradycyjny sposób uniksowy.

Myślę, że byłoby to typowe zastosowanie do list kontroli dostępu (ACL). Dodaj obu użytkowników (lub grupy) do listy ACL pliku konfiguracyjnego:

/etc/foo  root:root rw-------  # Traditional Unix ownership and permission for foo

$ setfacl -m użytkownik: bar: rw- / etc / foo # Umożliwia pasek użytkownika do odczytu i zapisu foo
$ setfacl -m użytkownik: baz: rw- / etc / foo # Pozwala również użytkownikowi baz na czytanie i pisanie foo

Najpierw może być konieczne zainstalowanie pakietu acl.

Ustaw tryb pliku 0660(lub nawet 0440jeśli zapis nie jest wymagany) i własność bar:baz. Wtedy jeden proces może uzyskać dostęp do pliku dzięki uprawnieniom użytkownika, a drugi dzięki uprawnieniom grupowym. Działa to nawet w systemach plików, w których listy ACL nie.

Prześlę to, ponieważ nie zostało jeszcze wspomniane. Chociaż prawdopodobnie nie tego chcesz, może to być odpowiedź dla innych osób z podobnym pytaniem.

„Nową” „chmurą” jest obsługa całej konfiguracji przez system zarządzania konfiguracją (np. Szef kuchni , marionetka lub ansible ). Nie ma wtedy znaczenia, że ​​masz dwa różne, ale identyczne pliki na serwerze, ponieważ oba są kopią jednego pliku z systemu zarządzania konfiguracją.

Główną zaletą robienia tego w ten sposób jest to, że twoja konfiguracja jest wersjonowana (wraz ze wszystkimi pozostałymi konfiguracjami), a wdrożenie nowego identycznego lub prawie identycznego serwera staje się tak łatwe, że można go zautomatyzować.

(Dla przypomnienia, ponieważ nie używasz zarządzania konfiguracją, wybrałbym system grupowy jak w odpowiedzi @ drg).