Існує технічна причина та проектна причина для поточної поведінки.
По-перше, snapd вимагає певної форми аутентифікації, оскільки він виконує операцію на рівні системи. У командному рядку ви можете використовувати sudo, як і коли ви apt install
, тому не потрібен онлайн-акаунт. Під час використання Програмного забезпечення єдиною формою аутентифікації на даний момент є магазин Snap. Обговорюються альтернативи ...
Я зробив спробу вирішити це, намагаючись отримати snapd згенерувати мигдальний без доступу до сховища. Але, як я розумію, отримання Макарунів вимагає поїздки в магазин.
Тому я думаю, що рішенням цього є або дозволити оснащення для створення локальних Macaroons або використовувати якийсь інший тип маркера аутентифікації для локального доступу. ( коментар 27 )
По-друге, автентифікація SSO була основною схемою дизайну, оскільки основним випадком використання Snappy є управління кількома пристроями IoT. Негативний вплив на користувачів настільних ПК та ноутбуків був незапланованим.
Чистий ефект - це набагато краща безпека для цих пристроїв ... подивіться, наприклад, сучасні точки доступу до Wi-Fi. Ви отримуєте єдиний обліковий запис управління, як правило, у хмарі, і ви керуєте всіма пристроями через це. ( коментар 25 )
Схоже, є план змінити поведінку, щоб користувачі настільних / ноутбуків не вимагали використовувати онлайн-акаунт для автентифікації. Ви можете підписатися на помилку, щоб отримувати новини, коли зміни вносяться.
Подача токена на root, який надає дозвіл на маніпулювання системою, аналогічна тому, що дозволяє самому root виконувати видалення без додаткової інформації про зберігання, що ми дозволяємо ... Необхідна інфраструктура для цього майже на місці, оскільки ми вже маємо підтримуйте локальні та віддалені макаруни окремо, і ситуація, коли віддалений макарун відсутня або неправильна, вже обробляється. ( коментар 29 )