I am a representative of EdgeIQ, and we are in the process of developing and refining our snap, now named “coda” (formerly known as “Edge Agent”) EdgeIQ Coda is designed to manage snaps on IoT devices as part of our IoT device management and workflow orchestration solutions.
To enhance the capabilities of our snap and ensure seamless device management, we request access to the snapd-control interface. This interface is critical for us to perform comprehensive device management tasks efficiently.
For reference, our public GitHub repository containing the snap build recipes can be found here: EdgeIQ Coda GitHub Repository.
Additionally, I would like to bring to your attention an issue we encountered with our previous revisions. Our earlier uploads requested snap-refresh-observe permissions and included a refresh hook (typo in the hook name), which have since been corrected. However, even after uploading the updated version, the Snapcraft dashboard still displays warnings and errors related to these permissions and hooks.
We kindly request assistance in resolving these warnings and errors to ensure our snap meets all necessary requirements and functions as intended.
The warning you’re seeing indicates that your snap is using an unknown hook (refresh), which is still present in revision #5 of your snap. The valid refresh related hooks are gate-auto-refresh, pre-refresh, and post-refresh. For a valid list of snap hooks, please see Supported snap hooks.
I also checked, and revision #5 still plugs snap-refresh-control.
Hello @awe . Thanks for your comments. I released that it was a caching issue on my side.
I’ve just pushed new revision #7 which address all of the issues above. I would appreciate your feedback on it.
Regarding the use of snapd-control - this is a super privileged interface and so is not generally granted. However, given the nature of the coda snap is to manage the snaps on a device, snapd-control is designed explicitly for this purpose.
Saying this though, snapd-control is not generally granted for such general purpose snaps in the global snap store - instead the use of a brand store / dedicated snap store might be more appropriate. In this case, you would be able to grant such use of snapd-control directly - @edgeiq can you comment?
Hello @alexmurray Sorry for the delay, I was on vacation last week.
The large enterprise clients of EdgeIQ who want to use snaps and Ubuntu Core on their devices typically have their own dedicated snap stores where they can store their private snaps. However, we don’t want to force our clients to manage and maintain the custom coda snap versions, which is the responsibility of EdgeIQ. Our clients just want the ability to cherry-pick the coda snap from public store into their custom stores.
So, the bottom line: EdgeIQ doesn’t have its own private store at this point and we don’t need it so far. Our clients do, but they don’t want to build or maintain custom version of coda snap in their stores - they just want to cherry-pick from the public store. Just to be on the same page - this request only covers the ability to publish the snap into the public store. We do NOT request auto-connect of the snapd-control interface. Granting access to manage snapd this is responsibility of the clients and this decision should be made by them explicitly.
I hope that this provides clarity on the use-cases. If you have any other questions please let me know.
@edgeiq thanks for getting back to me. Ok so in this case, I agree that manual connection of snapd-control seems reasonable for this snap to be published in the global store.
Given that this still grants device ownership for coda then we should also do publisher vetting. In this case that would best be done via the existing Verified Accounts process - could you please submit a request for this as well? Once that is processed we can then proceed with this request here. Thanks!
In addition to publisher vetting we will need at least two +1 votes from store reviewers in order to grant the required interface connection.
Whilst I’d be happy to support this request, I wonder if it will be possible to create declarations in a brand store for a snap that resides in the global store (@alexmurray). If it is possible, you could still maintain one unique version of coda in the global store and your customer could grant the required privileges only for their devices.
Hello @jslarraz thanks for joining this review. We assume that our clients will be able to manage auto-connection of interfaces via declarations in the own snap stores if they decide to do or do it manually. This their responsibility to decide grant auto-connect of interfaces or not.
As we mentioned above we just want to have a our snap published in the public snap store in order to be able deliver updates to our clients smoothly. We do NOT requesting snapd-control automatic connection in public store.
Sure, it sounds fine to me as far as we are talking about manual connection.
I was just wondering if it will be possible to enable you to publish the snap to the global store without allowing wide audience to consume it. It may be also interesting for some custom-device requests for specific hardware I guess. In my head it would work as follows:
We will approved the snap to be published in the global store, so your customers can consume the snap from there and you only need to maintain that copy.
No declaration is granted in the global store, so snapd will refuse to install the snap for the general audience.
Your customers creates the declaration in their brand store, so devices with their store configured can properly install the snap downloaded from the global store.
I don’t know if it is possible or even desirable. Just looking forward to hear @alexmurray opinion from the security perspective and also interested on your (@edgeiq) opinion regarding whether it will fulfill needs for your use case / similar use cases.
Of course if it can’t be done because of store limitation or it doesn’t meet your needs, I’m happy to go with granting connection to snapd-control interface directly in the global store.
I understand the concern about controlling access to the snapd-control interface. However, for our use case, it is essential that the coda snap is published in the global store and available to the general audience. Our clients wants to rely on the ability to cherry-pick the coda snap from the public store without the additional complexity of maintaining custom versions in their brand stores.
In order to show the benefits of Ubuntu Core and snaps to our existing and new customers, proof of concepts (PoC) are typically conducted by the R&D teams of our clients. We would like to make this process as smooth as possible because, at the early stages, they might not have a custom store yet. Having the coda snap easily accessible in the global store greatly facilitates these initial evaluations and PoCs.
The proposed solution of allowing the snap to be published in the global store but restricting its installation through snap declarations in brand stores is an interesting idea. However, it might introduce unnecessary complexity for our clients, who prefer a more straightforward approach.
We request that the coda snap be published in the global store with the snapd-control interface manually connected by users as needed. This approach aligns with our goal of providing easy access and management for our clients without imposing additional maintenance burdens on them.
I look forward to hearing @alexmurray’s opinion from the security perspective and welcome any further discussion on this matter.
The need for coda to be used directly from the global store is understood. As such, now that EdgeIQ is a verified publisher and we have the above two affirmative votes from myself and @jslarraz (“happy to support this request”) I have gone ahead and granted this request. Use of (but not auto-connect) of snapd-control for coda is now live. Please let me know if there are any issues.
We just want to say thank you for your support and guidance in the process of this application.
We and our clients are happy with the fact that snap is now available publicly.
