This request is following the discussion: Request snapd-control interface for ros2-snapd
And the development of the ros-snapd-support
interface.
This request has been added to the queue for review by the @reviewers team.
Hi @RoboticsCommunity!
Based on the previous discussion here, both requested interfaces make sense to me.
+1 vote for granting ros-snapd-support
and snap-refresh-observe
to snap ros2-snapd
(#voteFor).
What do the other @reviewers think?
Hey @RoboticsCommunity
Regarding the reasoning for snap-refresh-observe
, access to /apps endpoint should be granted by ros-snapd-support, should it? Moreover, snap-refresh-observe is intended to be used only to mark the existence of a refresh awareness client, according to the documentation (#askForInfo)
@jslarraz we used the refresh-observe to get access to /apps indeed. We could move the access to our ros-snapd-support interface, it’s a good suggestion.
But right now we would like to drop the snapd-control as soon as possible since we have a better and more secure solution even if not perfect.
After this change we will apply a new PR in our support interface and eventually when it reaches snapd stable we can also drop the refresh-observe.
What do you think?
Hey @mirkoferrati
I don’t know if I’m missing something but according to the documentation snap-refresh-observe does not grant access to /apps
Endpoint access permissions
/v2/changes
/v2/changes/{id}
/v2/icons/{name}/icon
/v2/notices
/v2/notices/{id}
/v2/snaps
/v2/snaps/{name}
On the other hand, ros-snapd-support seems to actually grant access to /apps already:
var (
appsCmd = &Command{
Path: "/v2/apps",
GET: getAppsInfo,
POST: postApps,
ReadAccess: interfaceOpenAccess{Interfaces: []string{"ros-snapd-support"}},
WriteAccess: interfaceAuthenticatedAccess{Interfaces: []string{"ros-snapd-support"}, Polkit: polkitActionManage},
}
logsCmd = &Command{
Path: "/v2/logs",
GET: getLogs,
ReadAccess: authenticatedAccess{Polkit: polkitActionManage},
}
)