Estou executando um processo de servidor no SMF (Server Management Facility) na imagem Base64 1.8.1 SmartOS da Joyent.
Para aqueles que não estão familiarizados com o SmartOS, é uma distribuição baseada em nuvem do IllumOS com KVM. Mas essencialmente é como o Solaris e herda do OpenSolaris. Portanto, mesmo se você não usou o SmartOS, espero explorar alguns conhecimentos do Solaris sobre ServerFault.
Meu problema é que eu quero que um usuário sem privilégios possa reiniciar um serviço que ele possui. 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 não privilegiado tem permissão para reiniciar, iniciar e parar seu próprio processo de servidor (isto é para implantações de código automatizadas).
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?
Respostas:
Porque svccfg (1M) está quebrado, e eu quebrei.
Em 2007, adicionei um recurso ao SMF que permitia grupos de propriedades que pudessem 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 tivesse privilégio (basicamente raiz) nem possuísse uma das autorizações nomeadas por essa propriedade seria incapaz de ler os valores de qualquer propriedade no grupo. Isso foi integrado nesse commit e é usado (pelo menos) pelos produtos de armazenamento Sun ZFS para armazenar itens como senhas LDAP.
Como parte desse trabalho, queríamos garantir que mesmo usuários privilegiados que pudessem ler esses valores não os expusessem acidentalmente exportando o estado de um serviço ou criando um arquivo do repositório SMF. Então, adicionei o sinalizador '-a' aos comandos de exportação e arquivamento no svccfg que exportariam explicitamente todos os valores de propriedade e alterei o padrão para excluir qualquer um que estivesse protegido contra leitura.
Infelizmente, essa restrição não está sendo aplicada corretamente; nesse 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, o uso da opção -a não ajudará aqui, porque quando 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 expor esses valores: a identidade das autorizações que permitem alterar o estado do serviço é realmente 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 visão dos outros, a menos que seja explicitamente desejado. Mas nas versões anteriores do S10, o XML e os arquivos exportados o continham, portanto foi definitivamente uma alteração incompatível. Você seria perdoado por estar chateado com isso. Mas o problema real aqui é que -a não funciona quando o grupo de propriedades em questão é "geral". Como você é a primeira pessoa a acertar isso, não faço ideia.
Você pode acompanhar esse problema em sua página, aqui . Enquanto isso, você pode considerar 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 esta questão à minha atenção.
fonte