It seems my mention of abstract domain sockets was missed, so I'll restate in more detail. This doesn't apply to juju-run, but it does apply to jujuc (the hook tools: relation-set, relation-get, etc.). The jujuc socket is an abstract domain socket, so it has no relationship to the filesystem; abstract domain sockets aren't affected by filesystem permissions. I think you have to use SCM_CREDENTIALS to do any kind of auth on those. This is technically a different bug I guess, but it would be good to at least consider how to fix that at the same time.
Seth: on Windows we use named pipes. We'll need to look at whether it is similarly affected, but that shouldn't hold up a fix for Linux. Looking at the gopkg.in/natefinch/npipe.v2 package, and the CreateNamedPipe docs, it appears that the default security descriptor is being used, which will restrict full access to administrators and the creator.
It seems my mention of abstract domain sockets was missed, so I'll restate in more detail. This doesn't apply to juju-run, but it does apply to jujuc (the hook tools: relation-set, relation-get, etc.). The jujuc socket is an abstract domain socket, so it has no relationship to the filesystem; abstract domain sockets aren't affected by filesystem permissions. I think you have to use SCM_CREDENTIALS to do any kind of auth on those. This is technically a different bug I guess, but it would be good to at least consider how to fix that at the same time.
Seth: on Windows we use named pipes. We'll need to look at whether it is similarly affected, but that shouldn't hold up a fix for Linux. Looking at the gopkg.in/ natefinch/ npipe.v2 package, and the CreateNamedPipe docs, it appears that the default security descriptor is being used, which will restrict full access to administrators and the creator.