Bug 1665643 - %selinux_modules_install doesn't work in new chroots/initial installs
Summary: %selinux_modules_install doesn't work in new chroots/initial installs
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 31
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1577199
TreeView+ depends on / blocked
Reported: 2019-01-12 01:14 UTC by Kevin Fenzi
Modified: 2019-08-16 08:18 UTC (History)
10 users (show)

Fixed In Version: selinux-policy-3.14.2-47.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-08-16 08:18:11 UTC
Type: Bug

Attachments (Terms of Use)

Description Kevin Fenzi 2019-01-12 01:14:53 UTC
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 $?

The macros need adjusting here to never exit 1 and hande the case where it is an initial install.

Comment 1 Michal Schorm 2019-01-14 11:13:37 UTC
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.

Should I undo it and prevent the update from reaching stable repository?

Comment 2 Adam Williamson 2019-01-14 17:48:02 UTC
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.

Comment 3 Ben Williams 2019-01-14 18:36:14 UTC
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)

Comment 4 Michal Schorm 2019-01-15 07:42:53 UTC
Alright, I disabled the autopush on that F29 MariaDB update and I won't push it forward until this bug will be resolved.

Comment 5 Lukas Vrabec 2019-01-15 16:26:58 UTC
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.


Comment 6 Pavel Raiskup 2019-01-16 10:17:00 UTC
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?

Comment 7 Adam Williamson 2019-01-16 17:16:31 UTC
Unless you think load_policy erroring for some reason should break installation *and* the creation of live and disk images, yes.

Comment 8 Fedora Update System 2019-01-17 09:06:32 UTC
selinux-policy-3.14.2-47.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-fe7af4a346

Comment 9 Pavel Raiskup 2019-01-17 09:09:41 UTC
(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

Comment 10 Pavel Raiskup 2019-01-17 09:10:40 UTC
That said - yes, if for some reason you plan to load_policy during
creation of live disk, it should break the installation.

Comment 11 Fedora Update System 2019-01-18 02:14:09 UTC
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.

Comment 12 Kevin Fenzi 2019-01-26 05:51:40 UTC
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...

Comment 13 Michal Schorm 2019-02-11 08:50:35 UTC
Any update here?
I don't know if I can release the MariaDB & MySQL packages with require on the 'mysql-selinux' package.

Comment 14 Pavel Raiskup 2019-02-11 10:22:20 UTC
While we are on it, can you please look at my question in comment #6?

Comment 15 Kevin Fenzi 2019-02-15 20:18:56 UTC
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.

Comment 16 Pavel Raiskup 2019-02-17 10:29:39 UTC
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.

Comment 17 Kevin Fenzi 2019-02-18 04:27:21 UTC
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...

Comment 18 Pavel Raiskup 2019-02-18 09:33:20 UTC
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:

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.

Comment 19 Pavel Raiskup 2019-02-18 09:34:33 UTC
(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:

Comment 20 Pavel Raiskup 2019-02-18 09:51:44 UTC
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-           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 $?

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.

Comment 21 Adam Williamson 2019-02-19 16:36:13 UTC
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.


Comment 22 Pavel Raiskup 2019-02-20 08:14:11 UTC
Ok, that is sad true, but valid.  Thank you Adam.

Comment 23 Pavel Raiskup 2019-02-20 08:19:35 UTC
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

Comment 24 Kevin Fenzi 2019-02-20 19:45:33 UTC
Note that while dnf itself is more tolerant, lorax/anaconda are not and a error like the above would fail the install.

Comment 25 Lukas Vrabec 2019-02-21 15:38:05 UTC
Pavel, Kevin, Adam,

I'm quite lost in this bugzilla, what's the last decision? Should I merge this PR:


and close this ticket? 


Comment 26 Pavel Raiskup 2019-02-22 06:14:40 UTC
(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.

Comment 27 Lukas Vrabec 2019-02-22 13:16:15 UTC
Make sense, Thanks for help Pavel. 

Let's wait for response from Kevin.

Comment 28 Kevin Fenzi 2019-02-22 22:29:05 UTC
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!

Comment 29 Pavel Raiskup 2019-02-23 10:06:24 UTC
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.


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'] += """

name="Copr repository"


So I'd propose https://src.fedoraproject.org/rpms/mariadb/pull-request/10 and we can have
deeper look later.

Comment 30 Tim Zabel 2019-08-02 17:49:15 UTC
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 ||: \`

Comment 31 Lukas Vrabec 2019-08-07 15:39:47 UTC
Hi Tim, 

I merged your PR Thanks! I created also selinux-policy build for rawhide:

Could you please try it if it works for you? 


Comment 32 Ben Cotton 2019-08-13 16:57:58 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 33 Ben Cotton 2019-08-13 17:34:24 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 34 Tim Zabel 2019-08-14 15:44:21 UTC

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

Comment 35 Tim Zabel 2019-08-15 22:58:00 UTC
Hey Lukas, 

Everything checks out. Feel free to mark this issue as fixed.

- Tim Zabel

Comment 36 Lukas Vrabec 2019-08-16 08:18:11 UTC
Hi Tim, 

Thanks for testing!


Note You need to log in before you can comment on or make changes to this bug.