SMF, SmartOS'a dışa aktarıldığında neden yapılandırma verilerini kaybediyor?

Joyent'ın Base64 1.8.1 SmartOS görüntüsündeki SMF (Sunucu Yönetim Tesisi) altında bir sunucu işlemi çalıştırıyorum.

SmartOS ile tanışmayanlar için, IllumOS'un KVM ile bulut tabanlı bir dağılımıdır. Ama aslında Solaris gibi ve OpenSolaris'ten miras. SmartOS kullanmasanız bile, ServerFault üzerinde bazı Solaris bilgisinden faydalanmayı umuyorum.

Benim sorunum, ayrıcalıksız bir kullanıcının sahip olduğu bir hizmeti yeniden başlatmasına izin verilmesini istiyorum. RBAC kullanarak ve bir yetkilendirme ekleyerek /etc/security/auth_attrve bu yetki kullanıcı ile ilişkilendirerek bunu nasıl yaptım.

Daha sonra hizmet için SMF bildirimime aşağıdakileri ekledim:

<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>

Ve bu içe aktarıldığında iyi çalışır. Ayrıcalıklı kullanıcımın kendi sunucu işlemini yeniden başlatmasına, başlatmasına ve durdurmasına izin verilir (bu, otomatik kod dağıtımları içindir).

Ancak, SMF bildirimini dışa aktarırsam, bu yapılandırma verileri kaybolur ... bu bölümde gördüğüm tek şey şu:

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

Bunun neden olduğunu bilen var mı? Sözdizim yanlış mı yoksa sadece SMF'yi yanlış mı kullanıyorum?

Çünkü svccfg (1M) bozuldu ve kırdım.

2007 yılında, SMF'ye, yalnızca uygun ayrıcalıklara sahip kullanıcılar tarafından okunabilen hassas bilgiler içerebilecek özellik gruplarına izin veren bir özellik ekledim. Fikir, bir özellik grubuna "read_authorization" özelliği ekleyebileceğiniz ve ne ayrıcalıklı (temelde kök) ne de o özellik tarafından adlandırılan yetkilerden birine sahip olan herhangi bir mülkün değerini okuyamayacağıydı. grupta. Bu, bu taahhüt altında entegre edildi ve (en azından) Sun ZFS depolama ürünleri tarafından LDAP şifreleri gibi şeyleri saklamak için kullanılır.

Bu çalışmanın bir parçası olarak, bu değerleri okuyabilen ayrıcalıklı kullanıcıların bile bir hizmetin durumunu dışa aktararak veya SMF deposunun bir arşivini oluşturarak bunları yanlışlıkla göstermeyeceğinden emin olmak istedik. Bu nedenle, svccfg'deki tüm özellik değerlerini açıkça dışa aktaracak dışa aktarma ve arşivleme komutlarına '-a' bayrağını ekledim ve okuma korumalı olanları hariç tutmak için varsayılanı değiştirdim.

Ne yazık ki, bu kısıtlama doğru bir şekilde uygulanmamaktadır; bu durumda, "genel" özellik grubunda belirli bir kaç özellik dışında bir özelliği dışa aktarmayı reddediyoruz. Geri kalanı herhangi bir değer olmadan dışa aktarılır, bu da gördüğünüz şeydir. Ne yazık ki, -a seçeneğini kullanmak burada yardımcı olmayacaktır, çünkü ilgili noktaya ulaştığımızda, artık bunu geçtiğinizi bilmek için gerekli içeriğe sahip değiliz. Bu bayrağın bu değerleri ortaya çıkarması gerekip gerekmediğini sorgulamak bile doğrudur: hizmet durumunu değiştirmeye izin veren yetkilerin kimliği gerçekten hassastır ve bir saldırgan için yararlı olacaktır. Kuşkusuz bunu yazdığımda aklımdaydı ve açıkça istenmedikçe bunu başkalarının görüşünden kısıtlamak mantıklı. Ancak önceki S10 sürümlerinde, dışa aktarılan XML ve arşivler içeriyordu, bu yüzden kesinlikle uyumsuz bir değişiklikti. Bu konuda üzüldüğünüz için affedilirsiniz. Ancak buradaki asıl sorun şu ki -a söz konusu mal grubu "genel" olduğunda işe yaramıyor. Buna ilk vuran siz nasılsın hiçbir fikrim yok.

Bu sorunu, sayfasından buradan takip edebilirsiniz . Bu arada, oluşturulan XML'deki özelliklerin değerlerini manuel olarak ekleyerek bu sorunu gidermeyi düşünebilirsiniz. Gerekirse bunları svcprop (1) aracılığıyla da okuyabileceğinizi unutmayın. Özür dilerim var. Bu soruyu dikkatime çektiği için Deirdre Straughan'a teşekkürler.