On 06/07/22 17:22, Richard W.M. Jones wrote: > On Tue, Jun 07, 2022 at 01:59:30PM +0100, Richard W.M. Jones wrote: >> On Mon, Jun 06, 2022 at 04:19:41PM +0200, Laszlo Ersek wrote: >>> + (* Disable SELinux temporarily around package installation. >>> Refer to >>> + * <https://bugzilla.redhat.com/show_bug.cgi?id=2028764#c7> and >>> + * <https://bugzilla.redhat.com/show_bug.cgi?id=2028764#c8>. >>> + *) >>> + fbs "setenforce 0" >>> + (sprintf "#!/bin/sh\n\ >>> + rm -f %s\n\ >>> + if command -v getenforce >/dev/null &&\n\ >>> + \ \ test Enforcing = \"$(getenforce)\"\n\ >>> + then\n\ >>> + \ \ touch %s\n\ >>> + \ \ setenforce 0\n\ >>> + fi\n" selinux_enforcing selinux_enforcing); >>> + fbs "install qga" inst_cmd; >>> + fbs "setenforce restore" >>> + (sprintf "#!/bin/sh\n\ >>> + if test -f %s; then\n\ >>> + \ \ setenforce 1\n\ >>> + \ \ rm -f %s\n\ >>> + fi\n" selinux_enforcing selinux_enforcing); >> >> Sounds horrible! But if that's what is needed ... > > OK, now I caught up with the BZ comments, it really seems odd to me > that a service or script can run dnf, but that dnf doesn't transition > to the right SELinux context in order to do its work, but also dnf > doesn't fail immediately ("error: wrong context!") either.
I've checked the fedora / selinux-policy.git contents; unfortunately most of the syntax is non-intuitive for me. I gathered that most system-level virt executables are labeled virtd_exec_t, including our own "firstboot.sh", but the same applies to the various libvirt daemons. Once they run, they somehow "decay" or get converted to "virtd_t", and that class (?) does not have the permission to transition to "rpm_script_t". It's like DNF just inherits the parent context, and when that context is a "root shell" (for example), then "rpm_script_t" can be transitioned to. Granting "rpm_script_t" globally to virtd_t would not be right (I doubt we want libvirt daemons to run RPM scripts), but do we really want "firstboot.sh" to have its own classification in the policy? And even so, it will not help with *existing*, installed guests, whose installed SELinux policies will not know about any such update. That's why I ultimately decided to just turn off SELinux temporarily: I see no way to retroactively convince installed (and converted) guests to grant additional *nuanced* permissions to "firstboot.sh". (We could forcibly run an --upgrade for the SELinux policy package, but what about old distros for which no updates will ever be released again?) This would not be a problem with installing qga immediately from the appliance (which does not use SELinux), but you explained why we prefer not to depend on network access during conversion; I don't want to challenge that. > > However I don't know enough about SELinux to really understand whether > this is how it's supposed to work or not. > > In reply to your other comment about --firstboot-install, it is > possible that this did work but has seen been broken by some change. > I don't believe we test it thoroughly anywhere. I think I'd like to stick with this kludge for now. Thanks Laszlo _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
