Dlaczego manifest SMF traci dane konfiguracyjne po wyeksportowaniu do SmartOS?

Prowadzę proces serwera w ramach SMF (Server Management Facility) na obrazie JOSENT Base64 1.8.1 SmartOS.

Dla tych, którzy nie są zainteresowani SmartOS, jest to oparta na chmurze dystrybucja IllumOS z KVM. Ale zasadniczo jest podobny do Solaris i dziedziczy po OpenSolaris. Więc nawet jeśli nie korzystałeś ze SmartOS, mam nadzieję, że wykorzystam trochę wiedzy o Solarisie na ServerFault.

Mój problem polega na tym, że chcę, aby nieuprzywilejowany użytkownik mógł zrestartować usługę, której jest właścicielem. Nauczyłem się, jak to zrobić, używając RBAC, dodając autoryzację /etc/security/auth_attri wiążąc ją z moim użytkownikiem.

Następnie dodałem następujące informacje do mojego manifestu SMF dla usługi:

<property_group name='general' type='framework'>
  <!-- Allow to be restarted-->
  <propval name='action_authorization' type='astring'
    value='solaris.smf.manage.my-server-process' />
  <!-- Allow to be started and stopped -->
  <propval name='value_authorization' type='astring'
    value='solaris.smf.manage.my-server-process' />
</property_group>

I działa to dobrze po zaimportowaniu. Mój nieuprzywilejowany użytkownik może zrestartować, uruchomić i zatrzymać własny proces serwera (dotyczy to automatycznych wdrożeń kodu).

Jeśli jednak wyeksportuję manifest SMF, dane konfiguracyjne znikną ... wszystko, co widzę w tej sekcji, to:

<property_group name='general' type='framework'>
  <property name='action_authorization' type='astring'/>
  <property name='value_authorization' type='astring'/>
</property_group>

Czy ktoś wie, dlaczego tak się dzieje? Czy moja składnia jest nieprawidłowa, czy po prostu nieprawidłowo używam SMF?

Ponieważ svccfg (1M) jest zepsuty, a ja go złamałem.

W 2007 roku dodałem funkcję do SMF, która pozwalała na grupy właściwości, które mogą zawierać poufne informacje, czytelne tylko dla użytkowników z odpowiednimi uprawnieniami. Pomysł polegał na tym, że można dodać właściwość „read_authorization” do grupy właściwości, a każdy, kto nie był ani uprzywilejowany (w zasadzie root) ani posiadał jednej z autoryzacji wymienionych przez tę właściwość, nie byłby w stanie odczytać wartości żadnej właściwości w grupie. Zostało to zintegrowane w ramach tego zatwierdzenia i jest używane przez (przynajmniej) produkty pamięci masowej Sun ZFS do przechowywania takich rzeczy, jak hasła LDAP.

W ramach tej pracy chcieliśmy się upewnić, że nawet uprzywilejowani użytkownicy, którzy mogą odczytać te wartości, nie ujawnią ich przypadkowo, eksportując stan usługi lub tworząc archiwum repozytorium SMF. Dodałem więc flagę „-a” do poleceń eksportowania i archiwizacji w svccfg, które jawnie eksportowałyby wszystkie wartości właściwości, i zmieniłem wartość domyślną, aby wykluczyć te, które były chronione przed odczytem.

Niestety to ograniczenie nie jest stosowane poprawnie; w tym przypadku po prostu odmawiamy wyeksportowania dowolnych oprócz kilku wybranych właściwości w „ogólnej” grupie właściwości z wartościami. Reszta jest eksportowana bez żadnych wartości, co właśnie widzisz. I niestety, użycie opcji -a nie pomoże tutaj, ponieważ do czasu, gdy osiągniemy odpowiedni punkt, nie mamy już kontekstu wymaganego, aby wiedzieć, że go zdałeś. Można nawet zadać pytanie, czy ta flaga powinna być wymagana do ujawnienia tych wartości: tożsamość autoryzacji, która umożliwia zmianę stanu usługi, jest rzeczywiście wrażliwa i byłaby przydatna dla osoby atakującej. Bez wątpienia miałem to na myśli, kiedy to napisałem, i rozsądne jest ograniczenie tego z widoku innych osób, chyba że jest to wyraźnie pożądane. Ale we wcześniejszych wersjach S10 wyeksportował XML i archiwa go zawierały, więc była to zdecydowanie niezgodna zmiana. Wybaczono by ci za to, że jesteś zdenerwowany. Ale prawdziwym problemem jest to, że -a nie działa, gdy dana grupa właściwości jest „ogólna”. Jak jesteś pierwszą osobą, która to trafiła, nie mam pojęcia.

Możesz śledzić ten problem na jego stronie tutaj . W międzyczasie możesz rozważyć obejście tego problemu, ręcznie dodając wartości właściwości do wygenerowanego pliku XML. Pamiętaj, że w razie potrzeby możesz je również odczytać za pomocą svcprop (1). Przepraszam. Dziękuję Deirdre Straughan za zwrócenie mojej uwagi na to pytanie.