I would love to see Snappy and users and groups (obsolete) fully designed and someone assigned to implement the various use cases, of which ‘1’ is specifically to address docker, lxd, etc. I don’t think it would take terribly long for someone to implement assuming we go with something along the lines of what I recommended.
I’d rather not open up the socket to be read/write by anyone on Ubuntu Core because the docker socket is a straight path to root for any users on the system or unconfined processes. It also requires code changes to docker to disable part of its security model which is undesirable.
IMHO, either docker should continue to say ‘run the docker command with sudo for now’ until the system users/groups feature is ready or we let it temporarily have account-control. It was mentioned that we don’t want to allow it because it would allow for confinement escape, but I don’t consider granting account-control as giving docker any more privilege to break out of confinement in practical terms.
docker-support is only advisory policy and we’ve always known that it allows multiple ways to break out of confinement (the most obvious is it has the ability to load apparmor policy into the kernel and therefore change its own confinement, so it could just give itself access to the user databases; this is one reason why the docker-support interface is so tightly controlled). Obviously, if the docker snap abused its advisory policy, that would be a problem that would need to be addressed through store processes and conversation with the publisher, but the point remains, the docker snap isn’t strongly confined and I don’t see that keeping it from using account-control as appreciably improving security.
I completely agree that using account-control in this way is abusing the interface (we need Snappy and users and groups (obsolete)). It is a gross hack to work around the missing feature and that might be grounds enough to not allow the access. That said, I envisioned the workaround of using account-control as temporary, only for docker and only until snapd properly supports system users and groups (and we would treat abuse of the account-control interface by the docker snap the same as abuse of the docker-support interface).