Hide Forgot
mysql-selinux was recently added as a recommends for mariadb. This pulled it into the kde-live media, however it has been breaking rawhide composes since then as it's %post exits 1 (error). I tried to work around this by adding || : at the end of the scriptlets, but they turn out to be macros and that doesnt work. We will need to change the macros themselves. The problem seems to be the call to /usr/sbin/selinuxenabled. The install is happening in a mock chroot and /sys is not available (and even if it was, builders have selinux in permissive mode). So it returns 1 and breaks the install. [root@buildhw-10 tmp]# sh -x post + . /etc/selinux/config ++ SELINUX=enforcing ++ SELINUXTYPE=targeted + _policytype=targeted + '[' -z targeted ']' + '[' targeted = targeted ']' + /usr/sbin/semodule -n -s targeted -X 200 -i /usr/share/selinux/packages/mysql.pp.bz2 + /usr/sbin/selinuxenabled [root@buildhw-10 tmp]# echo $? 1 The macros need adjusting here to never exit 1 and hande the case where it is an initial install.
Does it applicable for Fedora 29 too? I also merged the commit, which introduced the "Recommends:", to the F29 and a build with it included now lives happily in BODHI. https://bodhi.fedoraproject.org/updates/FEDORA-2019-7c5e0daf77 Should I undo it and prevent the update from reaching stable repository?
It will likely affect the semi-unofficial live respins of F29, but the better thing to do is probably just to get the macro fixed and backport that change to F29 too. I suggested to lvrabec that this line in the %selinux_modules_install macro: /usr/sbin/selinuxenabled && /usr/sbin/load_policy be changed to: /usr/sbin/selinuxenabled && /usr/sbin/load_policy || : the former returns 1 when selinuxenabled returns 1 (and thus the overall macro returns 1, and anaconda bails on the scriptlet error). The latter returns 0 in all cases.
please do not push this to F29 till it is fixed. F29 Gold iso are seeing 1.2GB of updates for new installs. and our current batch of updated isos are seeing 545MB. so we are planning to respin as soon as the 4.19.14 kernel is in the mirrors (pushing to stable today)
Alright, I disabled the autopush on that F29 MariaDB update and I won't push it forward until this bug will be resolved.
commit 8dd7ee29f3f4da520a718a314445d6b907c4f5a0 (HEAD -> master, origin/master, origin/HEAD) Author: Lukas Vrabec <lvrabec> Date: Tue Jan 15 16:33:41 2019 +0100 Some of the selinux-policy macros doesn't work in chroots/initial installs. BZ(1665643) Improve SELinux policy macros when /usr/sbin/selinuxenabled && /usr/sbin/load_policy is used and these tools returning exit code 1. This is issue for anaconda. https://github.com/fedora-selinux/selinux-policy-macros/commit/8dd7ee29f3f4da520a718a314445d6b907c4f5a0
Ad patch; instead of `aaa && bbb || true`, shouldn't we rather use `if aaa; then bbb; fi`? If selinuxenabled returns true, do we really want to ignore errors in load_policy?
Unless you think load_policy erroring for some reason should break installation *and* the creation of live and disk images, yes.
selinux-policy-3.14.2-47.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-fe7af4a346
(In reply to Adam Williamson from comment #7) > Unless you think load_policy erroring for some reason should break > installation *and* the creation of live and disk images, yes. In such cases /usr/sbin/selinuxenabled should be false, and thus fine. But it seems weird to ignore errors in load_policy _everywhere_.
That said - yes, if for some reason you plan to load_policy during creation of live disk, it should break the installation.
selinux-policy-3.14.2-47.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
This seems back again. 15:38:59,277 INF packaging: Installed: mysql-selinux-1.0.0-7.fc30.noarch 1547227303 df730755307149d8a414c11d53193c5bfa0f725cf82828c7063b9546febc0594 15:38:59,282 INF packaging: Configuring (running scriptlet for): mysql-selinux-1.0.0-7.fc30.noarch 1547227303 df730755307149d8a414c11d53193c5bfa0f725cf82828c7063b9546febc0594 15:39:12,562 ERR dnf.rpm: Error in POSTIN scriptlet in rpm package mysql-selinux 15:41:47,393 Level 8 dnf: RPM transaction over. 15:41:48,615 Level 8 dnf: timer: verify transaction: 1198 ms 15:41:48,618 Level 8 dnf: timer: transaction: 308774 ms 15:41:48,630 Level 8 dnf: Cleaning up. I'm going to untag the last 2 mariadb builds so we can get a rawhide...
Any update here? I don't know if I can release the MariaDB & MySQL packages with require on the 'mysql-selinux' package.
While we are on it, can you please look at my question in comment #6?
Basically we need to handle the state where we are running in a chroot (making media) and not error in that case at all. Any construction that does that should be ok for this bug/issue.
No, you don't want to have selinux enabled in such case, so the selinuxenabled should say false -- and no attempt to load_policy should follow. If load_policy is failing, you must be doing something wrong in chroot. That said, I disagree with the always-ignore-error `|| true` statement.
The initial problem was just the ordering I think. If you want to drop the || true stuff and are sure it won't error in a chroot, go ahead...
Ok, ordering.. I missed that. After the rpm fix from bug 1593185, doing `Requires: (mysql-selinux if selinux-policy-targeted) should order the RPM transaction properly. That said, if you do `dnf install -y mariadb selinux-policy-targeted` the installation and scriptlet execution should be done in order: 1. selinux-policy 2. selinux-policy-targeted 3. mysql-selinux, 4. mariadb > If you want to drop the || true stuff and are sure it won't error in a > chroot, go ahead... Here goes the PR: https://github.com/fedora-selinux/selinux-policy-macros/pulls What I'm not sure though is where the problem happens for you in the chroot, Kevin. Can you post more informative/detailed logs? From looking at the code, I can see that we _ignore_ errors in the preceding `semodule` call during %selinux_module_uninstall, but we don't ignore errors in %selinux_module_install: %{_sbindir}/semodule -n -s ${_policytype} -X %{!-p:200}%{-p*} -i %* \ Can this be the issue? @lvrabec, if selinux-policy-targeted was installed right before mysql-selinux, do you think that `semodule -i` should always succeed, even though we are running the command in chroot? It is really matter of definition how `semodule` should behave; blindly ignoring it's error status wouldn't make sense to me here either.
(In reply to Pavel Raiskup from comment #18) > Here goes the PR: > https://github.com/fedora-selinux/selinux-policy-macros/pulls I meant this one: https://github.com/fedora-selinux/selinux-policy-macros/pull/8
Btw., I tried it works OK for me like this: $ podman run --rm -ti registry.fedoraproject.org/fedora:30 bash .. [root@1e139e00942f /]# dnf install dnf-plugins-core -y .. [root@1e139e00942f /]# dnf copr enable praiskup/test-selinux-mariadb .. [root@1e139e00942f /]# dnf install mariadb-server selinux-policy-targeted # !!! note selinux-policy-targeted is mentioend as 2nd package to install Running transaction Running scriptlet: mariadb-connector-c-3.0.8-2.fc30.x86_64 1/1 .... Installing : python3-libselinux-2.9-0.rc1.1.fc30.1.x86_64 6/75 Installing : mariadb-connector-c-config-3.0.8-2.fc30.noarch 7/75 Installing : mariadb-common-3:10.3.12-20_praiskup.fc30.x86_64 8/75 Installing : mariadb-connector-c-3.0.8-2.fc30.x86_64 9/75 .... Installing : libselinux-utils-2.9-0.rc1.1.fc30.1.x86_64 11/75 Installing : policycoreutils-2.9-0.rc1.1.fc30.1.x86_64 12/75 Running scriptlet: policycoreutils-2.9-0.rc1.1.fc30.1.x86_64 12/75 Installing : rpm-plugin-selinux-4.14.2.1-4.fc30.1.x86_64 13/75 Installing : selinux-policy-3.14.3-22.fc30.noarch 14/75 Running scriptlet: selinux-policy-3.14.3-22.fc30.noarch 14/75 Running scriptlet: selinux-policy-targeted-3.14.3-22.fc30.noarch 15/75 Installing : selinux-policy-targeted-3.14.3-22.fc30.noarch 15/75 Running scriptlet: selinux-policy-targeted-3.14.3-22.fc30.noarch 15/75 .... Installing : mariadb-errmsg-3:10.3.12-20_praiskup.fc30.x86_64 18/75 Installing : python3-libsemanage-2.9-0.rc1.1.fc30.1.x86_64 19/75 Installing : python3-setools-4.1.1-14.fc30.x86_64 20/75 .... Installing : python3-audit-3.0-0.6.20181218gitbdb72c0.fc30.x86_64 48/75 .... Installing : checkpolicy-2.9-0.rc1.1.fc30.1.x86_64 66/75 Installing : python3-policycoreutils-2.9-0.rc1.1.fc30.1.noarch 67/75 Installing : policycoreutils-python-utils-2.9-0.rc1.1.fc30.1.noarch 68/75 Running scriptlet: mysql-selinux-1.0.0-8.fc30.noarch 69/75 Installing : mysql-selinux-1.0.0-8.fc30.noarch 69/75 Running scriptlet: mysql-selinux-1.0.0-8.fc30.noarch 69/75 libsemanage.semanage_direct_install_info: Overriding mysql module at lower priority 100 with module at priority 200. Installing : mariadb-backup-3:10.3.12-20_praiskup.fc30.x86_64 70/75 Installing : mariadb-cracklib-password-check-3:10.3.12-20_praiskup.fc30.x86_64 71/75 Installing : mariadb-gssapi-server-3:10.3.12-20_praiskup.fc30.x86_64 72/75 Installing : mariadb-server-utils-3:10.3.12-20_praiskup.fc30.x86_64 73/75 Running scriptlet: mariadb-server-3:10.3.12-20_praiskup.fc30.x86_64 74/75 Installing : mariadb-server-3:10.3.12-20_praiskup.fc30.x86_64 74/75 Running scriptlet: mariadb-server-3:10.3.12-20_praiskup.fc30.x86_64 74/75 Installing : mariadb-3:10.3.12-20_praiskup.fc30.x86_64 75/75 Running scriptlet: mysql-selinux-1.0.0-8.fc30.noarch 75/75 Running scriptlet: mariadb-3:10.3.12-20_praiskup.fc30.x86_64 75/75 Verifying : mariadb-3:10.3.12-20_praiskup.fc30.x86_64 .... [root@1e139e00942f /]# echo $? 0 .... The copr praiskup/test-selinux-mariadb only turns ON the conditional requirement in mariadb.spec. I see there's some stderr/stdout output during semodule execution, but that at least doesn't fail the transaction for me.
Note that ignoring errors in scriptlets is more or less policy: "All scriptlets MUST exit with the zero exit status. Because RPM in its default configuration does not execute shell scriptlets with the -e argument to the shell, excluding explicit exit calls (frowned upon with a non-zero argument!), the exit status of the last command in a scriptlet determines its exit status. Most commands in the snippets in this document have a “|| :” appended to them, which is a generic trick to force the zero exit status for those commands whether they worked or not. Usually the most important bit is to apply this to the last command executed in a scriptlet, or to add a separate command such as plain “:” or “exit 0” as the last one in a scriptlet. Note that depending on the case, other error checking/prevention measures may be more appropriate." or at least, you can do what you like with the errors, but the scriptlet *must* exit 0. https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
Ok, that is sad true, but valid. Thank you Adam.
JFTR, dnf seems to be more tolerant nowadays: .... Running scriptlet: dummy-pkg-20190220_0917-0.fc29.x86_64 1/2 some testing/debugging output warning: %post(dummy-pkg-20190220_0917-0.fc29.x86_64) scriptlet failed, exit status 1 Error in POSTIN scriptlet in rpm package dummy-pkg ....
Note that while dnf itself is more tolerant, lorax/anaconda are not and a error like the above would fail the install.
Pavel, Kevin, Adam, I'm quite lost in this bugzilla, what's the last decision? Should I merge this PR: https://github.com/fedora-selinux/selinux-policy-macros/pull/8 and close this ticket? Thanks, Lukas.
(In reply to Lukas Vrabec from comment #25) > Pavel, Kevin, Adam, > > I'm quite lost in this bugzilla, what's the last decision? I don't think we have a reproducer to justify comment #12, and thus I'd vote to rebuild maria and see whether it is still a problem. See comment #20 where I tested that it should simply work. Kevin, is it fine to re-try? > Should I merge > this PR: > > https://github.com/fedora-selinux/selinux-policy-macros/pull/8 Probably not, and it's orthogonal to this bug sorry.
Make sense, Thanks for help Pavel. Let's wait for response from Kevin.
Note that just testing in a container is not sufficent, as it already has the base os installed in it. Using dnf --installroot might do better or using livemedia-creator. but if you think it's ok now we can give it a try... I will be sure and let you know!
Using the following mock config, the `mock -r test.cfg --shell` did the --installroot right, too (no failures in scriptlets). ``` # This is development/testing only mock profile, not exactly the same as # is used on copr builders; but it is basically similar. If you need an # exact mock configuration (because you e.g. try to reproduce failed # build), such configuration is put alongside the built RPMs. include('/etc/mock/fedora-rawhide-x86_64.cfg') config_opts['root'] = 'praiskup-test-selinux-mariadb_fedora-rawhide-x86_64' config_opts['chroot_additional_packages'] = '' config_opts['chroot_setup_cmd'] = 'install @buildsys-build mariadb-server selinux-policy-targeted' config_opts['yum.conf'] += """ [copr_base] name="Copr repository" baseurl=https://copr-be.cloud.fedoraproject.org/results/praiskup/test-selinux-mariadb/fedora-rawhide-x86_64/ gpgcheck=0 enabled=1 skip_if_unavailable=1 metadata_expire=0 cost=1 best=1 """ ``` So I'd propose https://src.fedoraproject.org/rpms/mariadb/pull-request/10 and we can have deeper look later.
This is still very much an issue, and I would like this ticket reopened. When building an ISO in anaconda, and therefore in a chroot, SELinux modules will not be able to be installed. Currently, it seems all anaconda ISO builds will fail (as it does with mine -- reproducible). `%selinux_modules_install` should follow suit in adding a `|| :` after the semodule install. `%{_sbindir}/semodule -n -s ${_policytype} -X %{!-p:200}%{-p*} -i %* &> /dev/null ||: \`
Hi Tim, I merged your PR Thanks! I created also selinux-policy build for rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=36846000 Could you please try it if it works for you? Thanks, Lukas.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
Hello, I am still testing this bug out to make sure everything is going smoothly. I will update once I come to a resolution. Sorry for the delay, Tim Zabel
Hey Lukas, Everything checks out. Feel free to mark this issue as fixed. - Tim Zabel
Hi Tim, Thanks for testing! Lukas.