Existe uma razão técnica e uma razão de design para o comportamento atual.
Em primeiro lugar, o snapd exige alguma forma de autenticação, pois está executando uma operação no nível do sistema. Na linha de comando você pode usar o sudo, assim como quando você usa apt install , então nenhuma conta on-line é necessária. Ao usar o software, a única forma de autenticação atualmente disponível é o armazenamento Snap. Alternativas estão sendo discutidas ...
Eu tentei resolver isso tentando obter um Macaroon sem acesso à loja. Mas, pelo que entendi, conseguir um Macaroon requer uma ida e volta à loja.
Portanto, acho que a solução para isso é permitir que o snapd gere Macaroons locais ou use algum outro tipo de token de autenticação para acesso local. ( comentário 27 )
Em segundo lugar, a autenticação SSO era o padrão de design principal, porque o principal caso de uso do Snappy é o gerenciamento de vários dispositivos de IoT. O efeito negativo nos usuários de desktop / laptop não foi planejado.
O efeito líquido é uma segurança muito melhor para esses dispositivos ... veja os pontos de acesso Wi-Fi modernos, por exemplo. Você tem um único gerenciamento
conta, geralmente na nuvem, e você gerencia todos os dispositivos por meio disso. ( comentário 25 )
Parece que há um plano para alterar o comportamento para que os usuários de desktop / laptop não precisem usar uma conta on-line para fazer a autenticação. Você pode se inscrever no bug para receber notícias enquanto as alterações são feitas.
Distribuir um token para root que forneça uma autorização para manipular o sistema é análogo ao permitir que o próprio root faça remoções sem mais informações de armazenamento, o que permitimos ... A infraestrutura necessária para isso está praticamente no lugar desde que já tem que manter os macarons locais e remotos separadamente, e a situação em que o macaroon remoto está faltando ou incorreto já foi manipulado. ( comentário 29 )
