QEMU is unable to store Gluster specific debugging logs under /var/run/gluster/... This is because QEMU runs as user "qemu" and does not have write permissions there. This debugging (called 'statedump') can be triggered from the Gluster CLI which sends an event to QEMU (when libgfapi is used). When the glusterfs packages make sure that a group "gluster" has write permissions to /var/run/gluster/, could the qemu(-kvm-rhev) package be adjusted to have the "qemu" user in the "gluster" group? This would allow more debugging options that help with potential issues when QEMU runs with disk-images over libgfapi.so. From Cole in a reply (not archived in the list yet) to this email from Ademar about splitting the qemu package in sub-packages per block-backend: http://lists.ovirt.org/pipermail/devel/2017-April/030276.html > Since that work is already in fedora, it actually makes things easier there > for us, we can add the 'usermod -a -G gluster qemu' in the qemu-block-gluster > subpackage %pre, which will guarantee that qemu-common (which creates the > qemu user) and gluster packages (which create the gluster group) are already > on disk. > > OP please file a fedora qemu bug about this and we can go from there > > Thanks, > Cole
(In reply to Niels de Vos from comment #0) > QEMU is unable to store Gluster specific debugging logs under > /var/run/gluster/... This is because QEMU runs as user "qemu" and does not > have write permissions there. This debugging (called 'statedump') can be > triggered from the Gluster CLI which sends an event to QEMU (when libgfapi > is used). > > When the glusterfs packages make sure that a group "gluster" has write > permissions to /var/run/gluster/, could the qemu(-kvm-rhev) package be > adjusted to have the "qemu" user in the "gluster" group? This would allow > more debugging options that help with potential issues when QEMU runs with > disk-images over libgfapi.so. This feels like a pretty bad idea to me. If the /var/run/gluster directory is used for things not related to the "statedump", then you're giving QEMU access to them. Similarly if there are other files elsewhere (/etc, /var/lib, $whereever) that are access controlled based on the gluster group, then you'd again be giving QEMU access.
(In reply to Daniel Berrange from comment #1) > (In reply to Niels de Vos from comment #0) .. > This feels like a pretty bad idea to me. If the /var/run/gluster directory > is used for things not related to the "statedump", then you're giving QEMU > access to them. Similarly if there are other files elsewhere (/etc, > /var/lib, $whereever) that are access controlled based on the gluster group, > then you'd again be giving QEMU access. Currently the "gluster" group only has write permissions for /var/run/gluster. There are some other files (.pid) for processes in case the system is also used as a Gluster Storage Server, and not merely a Gluster client. Those other services are running as root, and therefore the files (.pid and some sockets) are only writable by root too. In the future we will have a function in libgfapi.so that makes it possible to configure a different path for statedumps on a per application basis. I am not sure yet how QEMU (+through libvirt) will be able to pass a "path for dumping debug files", and if this path needs to be Gluster specific. That is something I'll be asking on the QEMU devel list when libgfapi.so offers this functionality.
(In reply to Niels de Vos from comment #2) > In the future we will have a function in libgfapi.so that makes it possible > to configure a different path for statedumps on a per application basis. This seems like a better idea. What are "statedumps" and under what circumstances do they need to be written?
(In reply to Richard W.M. Jones from comment #3) > .... What are "statedumps" and under what circumstances do they need to be > written? Statedumps contain details about the operations that are in progress, status if inodes and memory allocations that are done by different translators (a translator is a layer implementing a certain functionality for the Gluster volume, like distribution, replication, cache, ...). A few more details about these files are written on https://github.com/gluster/glusterfs/blob/master/doc/debugging/statedump.md To get a statedump from an application that uses libgfapi.so, a request needs to be sent over the management connection from a storage server to the client. Executing the 'gluster' command with some parameters on a storage server is the normal way to do that. It is only used for debugging purposes when it is suspected that the Gluster client (here libgfapi.so with a set of translators) is misbehaving.
(In reply to Richard W.M. Jones from comment #3) > (In reply to Niels de Vos from comment #2) > > In the future we will have a function in libgfapi.so that makes it possible > > to configure a different path for statedumps on a per application basis. > > This seems like a better idea. What are "statedumps" and under > what circumstances do they need to be written? Agreed, that is the only viable approach from a security POV. Adding QEMU to the gluster group is just asking for trouble 6-12+ months down the line when some other critical file is access controlled based on the gluster group membership. So my suggestion is WONTFIX on this request.
It's possible to add a gluster-specific option for the path to QEMU's libgfapi driver.
(In reply to Paolo Bonzini from comment #6) > It's possible to add a gluster-specific option for the path to QEMU's > libgfapi driver. Yes, we would extend <qemu>/block/gluster.c to do have that, or use a more generic option that QEMU already has (like a working directory of some kind?). And then, we might need to teach libvirt and other projects to pass the option in case Gluster is used a block-driver. I aim to add the libgfapi.so configurable options to GlusterFS 3.12, which is at least 3 months out. Once the functionality is there, I'll get in touch on the qemu-devel list about the most suitable directory that can be used as default.
Seems like the idea of this bug (add qemu to gluster group) was abandoned, so closing. Please reopen if I misunderstood