I have a snap called
mailserver (source), it’s a snap that uses lxd to provision and manage a bunch of LXD containers for a full e-mail setup, the snap mostly contains the provision and management bits and the intention is to make it considerable easier for a somewhat novice or lazy sysadmin to run a full e-mail server.
It was truly a pain to try to get postfix and other tools to work inside a snap, and I changed to an idea based around the lxd snap. It works well, but last weekend I tried to upload my first draft and got rejected:
“The lxd interface is reserved for snaps that the ability to control all aspects of lxd containers on the system which therefore grants device ownership to the snap. If the access is required, consider using a brand store or create a forum topic at https://forum.snapcraft.io/ using the ‘store-requests’ category if this can be discussed in public or the ‘sensitive’ category if the discussion should remain private. Please feel free to copy and paste this message in the topic. Thanks!” — Jamie Strandboge
To control all aspects of the lxd containers is exactly what I like to do. I need to be able to create and manage several LXD containers, so I ask if it’s possible to grant my snap access to the lxd interface?
An alternative route for my snap it to use lxd remotes (access over the network), but it feels like it could open up a less secure solution for novice users, like if the user accidentally exposes lxd on the public internet and/or with a bad password. To be granted the lxd interface (to get access to the lxd socket) feels like a safer route, and easier to setup for the users. Also, the lxd snap is not auto-connected so the user must still manually (and intentionally) grant my snap access to lxd.
The lxd interface grants device ownership to the snap since it provides access to lxd’s socket for configuring all aspects of containers. Typically, difficulties in snapping an application (or stack) is not a reason to grant device ownership to the snap (whether classic or not).
-1 to auto-connect
I’m on the fence about granting the installation constraint since the interface gives device ownership and this snap is for the public store. If we granted the installation constraint, I think we’d need to perform the same level of vetting as a classic snap. If we had the same level of vetting as with classic, I would likely vote in favor of the installation constraint.
We’ve not had requests of this nature before, so I’m not voting yet until others respond. @pedronis and @reviewers - can you weigh in?
‘mailserver’ is also likely too generic of a name for this snap. Can you comment on the name or possible alternatives? @reviewers - can you also weigh on the name?
-1, feels far too generic
I agree that
mail-server is too generic a name, especially considering that it actually stands up multiple LXD containers. Perhaps
Also from me on the auto-connect of the lxd interface.
Thank you for the discussion,
I agree that this should absolutely not be auto connected, I’m completely fine to instruct the user how to connect the lxd interface manually, with a proper explanation of proper security considerations. The request is just simply to allow the snap in the store, and if if the lxd interface is not allowed I can grant my self the exact same access over the network, it was just cleaner, and more secure to use the socket.
I agree that from a security point of view the lxd interface could be problematic, if I had evil intent I could probably nuke an entire server, so to protect it in a similar manner like classic is probably sane. What type of vetting are you thinking about @jdstrand ?
The name: Feel like this is an separate discussion, but I feel that naming a snap that manages "an (e-)mail server, “mailserver” is not that strange. I got the inspiration from GNOME, basically just call it what ever it is. But is you really feel that this could confuse users (I do not want that) I will rename it.
To unblock my self I have moved over to accessing LXD over the network. This grants me the same access to the system, just over TCP instead of the socket. In both cases (TCP and Socket) the user needs to manually and explicitly grant me access to LXD, to be super clear, I have never asked for any auto-connect.
I’m still interested about the vetting process that @jdstrand mentioned, because I can imagine that there will be more snaps that has similar needs (for different reasons), for example top of my mind an lxd management UI would need the same type of access, or docker.
The snap is now fully approved and published by the system (because I removed lxd from plugs). The fact that you had opinions about the name, i’m afraid to move forward and then in a few months you will force me to rename it… if that’s the case I rather rename it now but I would like to understand why! @Wimpress @sparkiegeek @jdstrand
Well, the rationale for my -1 vote on the name is that I don’t believe that many people will expect
mail-server to be this software. I understand your rationale for naming it like that, but this appears to be a new, niche project which the wider world isn’t familiar with, and could easily be confused by.
Thank you, for the sake of not confusing people, it’s now renamed.
Thank you for renaming it. What did you name it to?
2 votes for, 0 against for allowing use of the ‘lxd’ interface
0 votes for, 2 against for allowing auto-connect of the ‘lxd’ interface (I know you didn’t request it, but doing this for clarity of the request)
Once you give the name, I’ll grant the declaration.
Thanks, this is now live.