On 06/15/2017 03:11 AM, Pavel Hrdina wrote: > On Tue, Jun 13, 2017 at 08:00:41PM -0400, John Ferlan wrote: >> >> >> On 05/29/2017 10:31 AM, Pavel Hrdina wrote: >>> In the case that virtlogd is used as stdio handler we pass to QEMU >>> only FD to a PIPE connected to virtlogd instead of the file itself. >>> >>> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1430988 >>> >>> Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx> >>> --- >>> >>> Notes: >>> new in v2 >>> >>> src/lxc/lxc_process.c | 6 ++--- >>> src/qemu/qemu_security.c | 9 +++++-- >>> src/security/security_apparmor.c | 7 ++++-- >>> src/security/security_dac.c | 54 +++++++++++++++++++++++++++++++--------- >>> src/security/security_driver.h | 6 +++-- >>> src/security/security_manager.c | 12 ++++++--- >>> src/security/security_manager.h | 6 +++-- >>> src/security/security_nop.c | 6 +++-- >>> src/security/security_selinux.c | 53 ++++++++++++++++++++++++++++++--------- >>> src/security/security_stack.c | 12 ++++++--- >>> tests/securityselinuxlabeltest.c | 2 +- >>> 11 files changed, 127 insertions(+), 46 deletions(-) >>> >> >> Why is it a (!chr_seclabel && chardevStdioLogd)? More to the point why >> is (!chr_seclabel) even matter? > > If you configure the label we shouldn't ignore it in some cases, that's > just wrong. If the label is set for the char device we will configure > it every time even if it will fail to start the guest, it's a > responsibility of the user to configure proper label if it is provided. > When email doesn't convey the question... Ugh... I'm also trying to speed learn an area of the code and review at the same time. If I go back to commit id 'f8b08d0e' where the original implementation to add labels for chardevs was done (but has been modified for patch 1 to change where the label is stored), I get the impression that a label should be added either from something specifically supplied for the <chardev> or to use the per domain one: "The source element may contain an optional seclabel to override the way that labelling is done on the socket path. If this element is not present, the security label is inherited from the per-domain setting." So if I look at the condition "(!chr_seclabel && chardevStdioLogd)" added by this patch to decide whether or not to supply the label, I'm left with the impression that if for this particular chardev a label doesn't exist *and* the configuration option chardevStdioLogd is true, then we're going to return happy status *and* not inherit the per-domain setting. So the bug is then that applying the default domain label for a chardev configured to use a stdio handle is incorrect? Perhaps I didn't get that from reading bz or the patch. >> IIUC, whether or not someone set the label for the chardev, for this >> particular issue/config where the chardev has a <log file=$path>, we >> don't want to set (or restore) the label. I feel like I'm missing >> something subtle. Maybe a bit more explanation of the adjustment would >> help me... > > This is not for the <log file=$path/> but for the <source path=$path/>. > We don't relabel $path for <log file=$path/> at all. > hmm.. ah, right... I kept scrolling back and forth in the bz and the docs, but missed this in the bz: 3) Check the virtlogd.log: error : virRotatingFileWriterEntryNew:113 : Unable to open file: /var/log/libvirt/qemu/log: Permission denied I guess I got lost in the power of suggestion of reading the docs regarding the "optional log file" that can be associated paragraph and trying to learn on the fly so that you at least get a review in a somewhat timely manner ;-) >> Wouldn't these changes end up selecting "any" chardev if >> chardevStdioLogd ended up being set regardless of whether they were >> actually using the log file? > > I don't know what you mean by this sentence? > Well let's see, chardevStdioLogd is set to true when meeting the two conditions a qemu.conf global "cfg->stdioLogd" && a per domain or emulator image capability "QEMU_CAPS_CHARDEV_FILE_APPEND". So, conceivably chardevStdioLogd could be true for *any* domain as long as those conditions are met, right? If you have a domain that has chardev's which are not configured to use the stdio handler, then the chardevStdioLogd could still be true, right? If that's the case and the chardev doesn't have a label associated, then we just return happy status and we do not inherit the per domain setting. Wouldn't that be incorrect? My concern is more we're making a change in a (mostly) common set of functions for a (very) specific problem. >> As an aside, I think there's an "oddity" when it comes to the Restore, >> but I'm not sure how to put it into words exactly. If a guest is running >> code prior to this set of changes, would it have successfully run a Set? >> If so, then after applying this change and restarting, the label >> wouldn't be reset, right? What happens at guest shutdown - does the >> label not get unset now? Of course this is all "interaction" with >> virtlogd restart that really throws a monkey wrench into things. > > No, that's not correct. The @chardevStdioLogd is stored in the status > XML (the one stored in /var/run/libvirt/qemu/$domain_name.xml). So when > the libvirtd is stopped and started with this patch applied the status > XML doesn't have the @chardevStdioLogd stored in it so it will be false > and we will reset the label. The @chardevStdioLogd is updated only when > the domain is started and we will store the value in the status XML > only with new libvirtd and only in that case we will not set/restore > the label. > hmmm.. Reading the bz indicates the 'virtlogd' daemon restarting... This is where all this gets a bit "odd" for me. Like I said it was a weird thing to even try and explain, but I think you talked me off the ledge of concern. John >> Also, why is the Smartcard chardev handling not using this > > The smartcard doesn't ever use virtlogd as stdio handler. > > Pavel > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
