Estou executando um processo de servidor em SMF (Server Management Facility) na imagem SmartOS Base64 1.8.1 de Joyent.
Para quem não conhece o SmartOS, é uma distribuição do IllumOS baseada em nuvem com KVM. Mas essencialmente é como o Solaris e herda do OpenSolaris. Portanto, mesmo que você não tenha usado o SmartOS, espero aproveitar algum conhecimento do Solaris no ServerFault.
Meu problema é que quero que um usuário sem privilégios tenha permissão para reiniciar um serviço de sua propriedade. Eu descobri como fazer isso usando o RBAC e adicionando uma autorização /etc/security/auth_attre associando essa autorização ao 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 sem privilégios 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 o que vejo nessa seção é o seguinte:
<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 simplesmente usando o SMF incorretamente?
Responder1
Porque svccfg(1M) está quebrado e eu quebrei.
Em 2007, adicionei um recurso ao SMF que permitia grupos de propriedades que poderiam conter informações confidenciais, legíveis apenas por usuários com privilégios apropriados. A ideia era que você pudesse adicionar uma propriedade "read_authorization" a um grupo de propriedades, e qualquer pessoa que não fosse privilegiada (basicamente, root) nem possuísse uma das autorizações nomeadas por essa propriedade não seria capaz de ler os valores de qualquer propriedade. no grupo. Isto foi integrado sobeste 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 usuários privilegiados que pudessem ler esses valores não os exporiam acidentalmente exportando o estado de um serviço ou criando um arquivo do repositório SMF. Portanto, adicionei o sinalizador '-a' aos comandos de exportação e arquivamento no svccfg que exportaria explicitamente todos os valores de propriedade e alterei o padrão para excluir aqueles que estivessem protegidos contra leitura.
Infelizmente, esta restrição não está a ser aplicada correctamente; neste caso, simplesmente nos recusamos a exportar apenas algumas propriedades selecionadas no grupo de propriedades "geral" com valores. O restante é exportado sem nenhum valor, que é o que você está vendo. E infelizmente, usar a opção -a não vai ajudar aqui, porque quando chegarmos ao ponto relevante, não teremos mais o contexto necessário para saber que você passou por isso. É até justo questionar se este sinalizador deveria ser necessário para expor esses 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 isto, e é razoável restringir isso da visão dos outros, a menos que seja explicitamente desejado. Mas nas versões anteriores do S10, o XML exportado e os arquivos o continham, 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ê foi a primeira pessoa a acertar isso, não tenho ideia.
Você pode acompanhar esta edição em sua página, aqui. Enquanto isso, você pode considerar uma solução adicionando manualmente os valores das propriedades no XML gerado. Observe que você também pode lê-los via svcprop(1) se necessário. Você tem minhas desculpas. Agradeço a Deirdre Straughan por chamar minha atenção para esta questão.