On Monday 08 February 2016 19:34:10 Richard W.M. Jones wrote:
On Wed, Feb 03, 2016 at 01:17:42PM +0100, Pino Toscano wrote:
Introduce a new read-only API to get a path where to store temporary sockets: this is different from tmpdir, as we need short paths for sockets (due to sockaddr_un::sun_path), and it is either XDG_RUNTIME_DIR if set, or /tmp; adapt guestfs_int_create_socketname to create sockets in that location.
Furthermore, print sockdir and XDG_RUNTIME_DIR in test-tool for debugging.
As you saw, there were a few problems with this patch. However I also found something more fundamental.
On machines where XDG_RUNTIME_DIR is set to /run/user/$UID, it fails badly when run as root:
Original error from libvirt: internal error: process exited while connecting to monitor: 2016-02-08T19:17:42.375986Z qemu-system-x86_64: -chardev socket,id=charserial0,path=/run/user/0/libguestfsdittS9/console.sock: Failed to connect socket: Permission denied [code=1 int1=-1]
This is because libvirt runs the appliance as qemu.qemu, which cannot access /run/user/0 (mode 0700).
This is the default configuration when accessing a remote machine using `ssh root@remote virt-tool ...'
This is not due to the work itself, but to the limitations coming from other parties involved (libvirt in this case).
I think we should drop all references to XDG_RUNTIME_DIR (as I noted before, I don't have a high regard for freedesktop pseudo-standards, which I believe are just a way for some people to "policy launder" junk into Linux).
There isn't any needed to scrap everything at the first issue, there actually is a way to make this work better. Also, not having high regards does not automatically mean that things are obnoxious, not that there isn't any middle ground possible.
The attached patch does that. Note the get-sockdir function now returns the hard-coded value "/tmp", which may or may not be a good idea.
NACK for me. Attached there is a (IMHO) better approach to the issue found with libvirt: since only root needs particular changes, then limit them only for this user. After all, we all recommend using libguestfs and its tools as normal user as much as possible, right? So we shouldn't make the common user case worse only for non-recommended use cases. Thanks, -- Pino Toscano