Dwa programy setuid /usr/bin/bar
i /usr/bin/baz
współdzielą jeden plik konfiguracyjny foo
. Trybem pliku konfiguracyjnego jest 0640
przechowywanie 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/foo
i /etc/baz/foo
. Nie udaje się to jednak, ponieważ plik, o ile wiem, musi należeć do root:bar
lub do root:baz
.
Potencjalne rozwiązanie: Utwórz nową grupę, barbaz
której członkami są bar
i baz
. Niech foo
należy do root:barbaz
.
To dla mnie wygląda na ciężkie rozwiązanie. Czy nie ma prostszego, prostszego sposobu udostępniania pliku konfiguracyjnego foo
mię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).
ssl-cert
grupa, która jest właściwie twojąbarbaz
grupą. Standardem jest ustawienie wszystkich kluczy prywatnych, które mają być własnościąssl-cert
grupy, i umieszczenie identyfikatorów UID powiązanych z programami, które muszą uzyskać do nich dostęp, w tej grupie.ssl-cert
którego skrypt postinst podczas instalacji tworzy grupę, o której mówisz. Nie byłem tego świadomyssl-cert
. Apache2 (zainstalowany na moim hoście) zalecassl-cert
. Różne pakiety Exim i Dovecot nie, ale Postfix (nie zainstalowany na moim hoście) zależy odssl-cert
. Ze względu na Apache mój host ma grupę ssl-cert , ale ta grupa nie ma jeszcze członków. Dzięki za radę.Odpowiedzi:
Możesz używać list ACL, aby plik mógł być odczytany przez osoby w obu grupach.
Teraz oboje
bar
ibaz
grup można odczytać pliku.Na przykład, oto plik należący do bin: bin w trybie 640.
Te
+
środki Tam jest zestaw ACL, więc rzućmy okiem na to.Widzimy linię
group:sweh:r--
: oznacza to, że ludzie w grupiesweh
mogą ją przeczytać.Hej, to ja!
I tak, mogę odczytać plik.
źródło
Możesz ponownie rozważyć te stwierdzenia:
Dlaczego ciężko jest stworzyć nową grupę? Ma to następujące zalety w porównaniu z listami ACL:
/usr/bin/bar
i/usr/bin/baz
waż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).Osobiście uważam, że listy ACL są tu ciężkim rozwiązaniem, a grupują jako prostszy, tradycyjny sposób uniksowy.
źródło
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:
Najpierw może być konieczne zainstalowanie pakietu acl.
źródło
Ustaw tryb pliku
0660
(lub nawet0440
jeś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.źródło
„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).
źródło