Há uma razão técnica e uma razão de design para o comportamento atual.
Em primeiro lugar, o snapd requer 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 apt install
, portanto, nenhuma conta online é necessária. Ao usar o Software, a única forma de autenticação atualmente disponível é a loja Snap. Alternativas estão sendo discutidas ...
Fiz uma tentativa de resolver isso, tentando obter snapd para gerar um Macaroon sem acesso à loja. Mas, pelo que entendi, comprar um Macaroon exige uma ida e volta à loja.
Portanto, acho que a solução é 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 caso de uso principal do Snappy está gerenciando 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 modernos pontos de acesso wifi, por exemplo. Você obtém uma única conta de gerenciamento, geralmente na nuvem, e 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 online para se autenticar. Você pode se inscrever no bug para receber notícias conforme as alterações são feitas.
Distribuir um token para o root que forneça uma autorização para manipular o sistema é análogo a permitir que o próprio root faça remoções sem obter mais informações de armazenamento, o que permitimos ... A infraestrutura necessária para isso está praticamente em vigor, pois já precisamos mantenha os macaroons locais e remotos separadamente e a situação em que o macaroon remoto está ausente ou incorreto já está sendo tratado. ( comentário 29 )