Por que o SMF está perdendo dados de configuração quando exportados no SmartOS?

Question

Estou executando um processo de servidor no SMF (Server Management Facility) na imagem SmartOS do Base64 1.8.1 do Joyent.

Para aqueles que não estão familiarizados com o SmartOS, é uma distribuição baseada na nuvem do IllumOS com o KVM. Mas essencialmente é como o Solaris e herda do OpenSolaris. Portanto, mesmo que você não tenha usado o SmartOS, espero usar alguns conhecimentos do Solaris no ServerFault.

Meu problema é que eu quero que um usuário sem privilégios tenha permissão para reiniciar um serviço de sua propriedade. Eu tenho trabalhado como fazer isso usando o RBAC e adicionando uma autorização para /etc/security/auth_attr e associando essa autorização com meu usuário.

Em seguida, adicionei o seguinte ao meu manifesto SMF para o serviço:

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

E isso funciona bem quando importado. Meu usuário não privilegiado tem permissão para reiniciar, iniciar e interromper seu próprio processo de servidor (isso é para implantações automatizadas de código).

No entanto, se eu exportar o manifesto SMF, esses dados de configuração desaparecerão ... tudo que vejo nessa seção é:

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

Alguém sabe por que isso está acontecendo? Minha sintaxe está errada ou estou usando o SMF incorretamente?

    

Answer 1

Porque o svccfg (1M) está quebrado e eu o quebrei.

Em 2007, adicionei um recurso ao SMF que permitia grupos de propriedade que podiam conter informações confidenciais, legíveis somente por usuários com privilégios apropriados. A idéia era que você poderia adicionar uma propriedade "read_authorization" a um grupo de propriedades, e qualquer pessoa que não fosse privilegiada (basicamente, root) nem possuir uma das autorizações nomeadas por essa propriedade seria incapaz de ler os valores de qualquer propriedade. no grupo. Isso foi integrado em este commit e é usado (pelo menos) pelos produtos de armazenamento Sun ZFS para armazenar coisas como senhas LDAP.

Como parte desse trabalho, queríamos ter certeza de que mesmo os usuários privilegiados que conseguissem ler esses valores não os exporiam acidentalmente exportando o estado de um serviço ou criando um arquivo do repositório do SMF. Então, adicionei o sinalizador '-a' aos comandos de exportação e arquivamento em svccfg que explicitamente exportavam todos os valores de propriedade e alteravam o padrão para excluir qualquer um que fosse protegido por leitura.

Infelizmente, essa restrição não está sendo aplicada corretamente; Nesse caso, simplesmente nos recusamos a exportar qualquer propriedade, exceto algumas, no grupo de propriedades "gerais" com valores. O resto é exportado sem nenhum valor, que é o que você está vendo. E infelizmente, usar a opção -a não ajudará aqui, porque no momento em que chegamos ao ponto relevante, não temos mais o contexto necessário para saber que você passou por isso. É justo questionar se esse sinalizador deve exigir a exposição desses valores: a identidade das autorizações que permitem alterar o estado do serviço é de fato sensível e seria útil para um invasor. Sem dúvida, isso estava em minha mente quando escrevi isso, e é razoável restringir isso da opinião dos outros, a menos que seja explicitamente desejado. Mas nas versões anteriores do S10, o XML exportado e os arquivos continham isso, então foi definitivamente uma alteração incompatível. Você seria perdoado por estar chateado com isso. Mas o verdadeiro problema aqui é que -a não funciona quando o grupo de propriedades em questão é "geral". Como você é a primeira pessoa a acertar isso eu não tenho ideia.

Você pode seguir este assunto em sua página aqui . Enquanto isso, você pode pensar em contornar isso adicionando manualmente os valores das propriedades no XML gerado. Note que você também pode lê-los via svcprop (1), se necessário. Você tem minhas desculpas. Agradeço a Deirdre Straughan por trazer essa questão à minha atenção.