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