|
From: | Eric Blake |
Subject: | Re: QAPI schema for desired state of LUKS keyslots |
Date: | Mon, 17 Feb 2020 06:44:34 -0600 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 |
On 2/17/20 6:28 AM, Markus Armbruster wrote:
Proposal: { 'enum': 'LUKSKeyslotState', 'data': [ 'active', 'inactive' ] } { 'struct': 'LUKSKeyslotActive', 'data': { 'secret': 'str', '*iter-time': 'int } } { 'struct': 'LUKSKeyslotInactive', 'data': { '*old-secret': 'str' } } { 'union': 'LUKSKeyslotAmend', 'base': { '*keyslot': 'int', 'state': 'LUKSKeyslotState' } 'discriminator': 'state', 'data': { 'active': 'LUKSKeyslotActive', 'inactive': 'LUKSKeyslotInactive' } } LUKSKeyslotAmend specifies desired state for a set of keyslots.Though not arbitrary sets of keyslots, it's only a single keyslot or multiple keyslots containing the same secret. Might be good enough in practice, though it means that you may have to issue multiple amend commands to get to the final state that you really want (even if doing everything at once would be safe).True. I traded expressiveness for simplicity. Here's the only practical case I can think of where the lack of expressiveness may hurt: replace secrets. With this interface, you need two operations: activate a free slot with the new secret, deactivate the slot(s) with the old secret. There is an intermediate state with both secrets active. A more expressive interface could let you do both in one step. Relevant only if the implementation actually provides atomicity. Can it?
Or put another way, can atomicity be added via 'transaction' later? If so, reusing one common interface to provide atomicity is nicer than making every interface reimplement atomicity on an ad hoc basis.
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
[Prev in Thread] | Current Thread | [Next in Thread] |