Hello,
I’d like to request the snapd-control interface for ros2-snapd.
ros2-snapd is an application that bridges part of snapd API to the ROS 2 framework allowing to list/start/stop/restart snap services directly from ROS 2. The intended use case is to delegate the service orchestration to an existing robotics state-machine of sort.
Thanks.
Hi @artivis ,
Similarly to your other request I can’t find ros2-snapd. Have you published a release?
Regards,
David
@lofidevops,
I’ve tried to push a first revision on ros2-snapd (yep it is different from ros-snapd :D) which upload failed with a Upload status: Manual review pending.
Mind that I opened this request from my personal account while the ros2-snapd snapd is owned by the team account Ubuntu Robotics Community .
I’ve escalated the manual review and hopefully will have a response shortly.
Hello!
The snapd-control interface is very powerful and allows the snap to bypass all confinement. While the rationale you have given makes a good case for requiring snapd-control, I am copying @reviewers to see if there is another way to achieve the requirement (i.e. without having to restart snap services).
BR Najam
Hey @artivis
Just to be sure, the privilege level provided by snapd-control interface is only intended to be used by code that is developed as part of the ROS 2 framework. Applications developed to use the ROS 2 framework (but that are not part of it) will not be able to consume this functionality by any means. Is that right?
Hello,
I’ve pushed the ros-snapd snap on the store (under the Ubuntu Robotics Community account again). It is the very same app but targeted to ROS 1. Should open a new, separate request or could I shove it in this thread since it is essentially the same?
Hi @jslarraz,
I’m not sure to fully grasp the extend of your question. This app exposes the start/stop/restart functionality through the ROS 2 API which relies (at the moment) on the DDS protocol. So realistically, anything that ‘speaks’ DDS, be it wrapped in ROS 2 or not, would likely be able to call this app’s functionality.
So it means that if ros2-snapd is installed in the system, any process (snapped or not) will be able to list/start/stop/restart snap services with no further check via the ROS 2 API? For environment where ros2-snapd is expected to be installed, It is equivalent to grant snap-control to all snaps, isn’t it?
It is indeed equivalent to granting list/start/stop/restart to any process speaking ROS 2 / DDS.
That’s what I was afraid of . I don’t think it fits snap confinement model tbh
@alexmurray @pedronis Thoughts?
@artivis can you clarify whether ros2-snapd mediates this call? ie. does it only restrict the use of list/start/stop/restart to only ROS processes / snaps? If so then I think this may be appropriate to grant (however, if it does not mediate this itself and allows any ROS process to call this on any other snap then that would be bad).
After some discussion, we agreed that a new interface that only allows to list/start/stop/restart snap services will be better than snap-control from the security point of view. The publishers will work to create such an interface.
In the mean time +1 from me for allowing ros-snapd and ros2-snapd to manually connect snapd-control interface
+1 from me too on the proviso that the use of snapd-control is a temporary measure until the proposed snap-service-control or somesuch interface is provided by snapd.
+2 for, 0 against. Publisher is vetted. Granting the use of snapd-control interface without auto-connect. This is now live
Thanks
