Details
-
Bug
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
production
-
None
Description
On any Unix VMs created for Coin and debug use by developers, provisioning should leave ~qt/ and everything under it owned by user qt. At present, it tends to leave stray things owned by root instead, which makes life needlessly tiresome for a developer debugging on such a VM and could potentially cause problems for tests being run on one.
For example, today I got a macos-14-arm64-developer-build-tests on which to investigate a precheck failure and initially couldn't scp my ssh public key to its ~qt/.ssh/ because it was root-owned (with, sensibly enough, restrictive privileges) until I did a sudo chmod qt to it; and then I hit the same with its authorized_keys (to which I wanted to append my public key, to make logging in easy). I've previously seen this on a VM with ~qt/.bash_history unwritable by user qt, so commands I used in one visit weren't remembered next time I logged in. In similar ways, if a file that user-processes expect to be able to write to might be modified by some test, or indeed by our build tools, that could lead to issues if it's owned by root.
As a rule of thumb, if there's a reason for the content to not be owned by user qt then that's also a reason for it not to be in that user's home directory; and if there isn't a strong reason for content on the disk to be owned by root then it should be owned by some less privileged user.
One possible resolution of this would be for provisioning to set up a second unprivileged user account, say provisioner, and have as much as possible of provisioning be done in its home directory, preferably by processes running as this unprivileged user, with root only doing the parts that must be done by root. This would both reduce clutter in ~qt/ and reduce the risk of bad ownership of files affecting either integrations or efforts to debug their failures.