daemon: secureboot updates API endpoint #14541
Conversation
github-actions
bot
added
the
Needs Documentation -auto-
daemon/api_system_secureboot.go
Outdated
| } | ||
|
|
||
| switch req.Action { | ||
| case "efi-secureboot-db-update": |
There was a problem hiding this comment.
having action and subaction is a bit unusual, also at least the startup action might be relevant to more types of fw updates than db-updates? can't we fold things into actions:
efi-secureboot-update-startup
efi-secureboot-update-db-prepare
efi-secureboot-update-db-cleanup?
is cleanup perhaps also relevant to other kind of updates?
daemon/api_system_secureboot.go
Outdated
| // TODO should this be only allowed for services with fwupd on slot | ||
| // side? |
There was a problem hiding this comment.
yes, as disussed we care about the slot side here, not the plug
daemon/api_system_secureboot.go
Outdated
| var systemSecurebootCmd = &Command{ | ||
| // TODO GET returning whether secure boot is relevant for the system? | ||
|
|
||
| Path: "/v2/system/secureboot", |
There was a problem hiding this comment.
looking at other end points it seems this might need to be /v2/system-secureboot ?
There was a problem hiding this comment.
I was wondering if there's a use case for exposing other properties of the system, eg disks (or storage), gadget, in which case those could be hosted at /v2/system/disks, and so on. wdyt?
Stubs Signed-off-by: Maciej Borzecki <[email protected]>
… process being root Add a new access checker which verifies that the request is coming from a root user and if the process is a snap, a required interface is connected, with that snap present on the slot side. Signed-off-by: Maciej Borzecki <[email protected]>
…ureboot key DBs Add a new endpoint for integration with a local manager of EFI secureboot key databases. Signed-off-by: Maciej Borzecki <[email protected]>
bboozzoo
force-pushed
the
bboozzoo/efi-secureboot-api
branch
from
68afd04
to
70eed3e
Compare
| func postSystemSecurebootActionJSON(c *Command, r *http.Request) Response { | ||
| var req struct { | ||
| Action string `json:"action,omitempty"` | ||
| Data *json.RawMessage `json:"data"` |
There was a problem hiding this comment.
I would avoid having this nested "data" level, just define a top level struct with the field we need with a validate method that checks if field that should be set for a given op are or than't shouldn't aren't
Add a dedicated integration API endpoint for controlling/notifying of secure boot keys databases updates.
This is a draft PR with no unit tests, with the purpose of validating the API endpoint and the policy around it.
Related: SNAPDENG-32364 SNAPDENG-31856