rpms / selinux-policy

Clone
Source Code
GIT

#128 %selinux_requires: use weak dependency to "require" specific version
Opened 3 years ago by vmojzis. Modified 2 months ago
rpms/ vmojzis/selinux-policy recommends  into  rawhide

Merge
file modified
+5 -2 
@@ -19,6 +19,8 @@ 
 

  # RPM macros for packages installing SELinux modules
 

  

  %_selinux_policy_version SELINUXPOLICYVERSION
 

+ # To be updated after major policy changes
 

+ %_selinux_policy_stable_version 38.25
 

  

  %_selinux_store_path SELINUXSTOREPATH
 

  %_selinux_store_policy_path %{_selinux_store_path}/${_policytype}
 
@@ -31,11 +33,12 @@ 
 

  

  # %selinux_requires
 

  %selinux_requires \
 

- Requires: selinux-policy >= %{_selinux_policy_version} \
 

+ Requires: selinux-policy >= %{_selinux_policy_stable_version} \
 

+ Recommends: selinux-policy >= %{_selinux_policy_version} \
 

  BuildRequires: pkgconfig(systemd) \
 

  BuildRequires: selinux-policy \
 

  BuildRequires: selinux-policy-devel \
 

- Requires(post): selinux-policy-base >= %{_selinux_policy_version} \
 

+ Requires(post): selinux-policy-base >= %{_selinux_policy_stable_version} \
 

  Requires(post): libselinux-utils \
 

  Requires(post): policycoreutils \
 

  %if 0%{?fedora} || 0%{?rhel} > 7\

selinux_requires macro ensures that each DSP package requires
selinux-policy package in version that was present during build of given
DSP package, or newer. This feature may cause issues if buildroot
contains newer selinux-policy package than what is available in
production - DSP package built in such buildroot would be inpossible to
install in production (because only older selinux-policy is available
there).

  • Use "Recommends" instead of "Requires" for selecting specific
    selinux-policy version.
  • Add non-versioned selinux-policy requirement for cases when
    "--setopt=install_weak_deps=False" is used, or given selinux-policy
    version is not available (as described above)

How could happen that a DSP package is available in production before selinux-policy build which was used during build?

What if the buildroot selinux-package contained new permission covered by some existing interface which is used in the DSP package?

I don't think this is the right approach.

Build failed.

In the commit message, I miss an explanation for why you are making this change. You talk about new problems that this introduces, but not about the problem that you're trying to solve in the first place.

How could happen that a DSP package is available in production before selinux-policy build which was used during build?

In a rare case where the buildroot contains newer package than what was released to production.

What if the buildroot selinux-package contained new permission covered by some existing interface which is used in the DSP package?

Than the installation would fail. But new permissions (and other constructs that can cause incompatibility) are added very rarely. In most cases the DSP module will work with older selinux-policy package. This patch should only make a difference in the rare event described above (buildroot contains newer version of selinux-policy) and will solve the issue in most cases (without it, the DSP package cannot be installed at all, which may even block the installation of the parent package -- e.g. freeipa cannot be installed because of freeipa-selinux).

I don't think this is the right approach.

In the commit message, I miss an explanation for why you are making this change. You talk about new problems that this introduces, but not about the problem that you're trying to solve in the first place.

The first paragraph actually describes the current state -- i.e. the problem I'm trying to solve.
I'll try to rewrite it so that it's easier to understand.

rebased onto 3bb008f8fc6c7afaadc88d536b9e956dc954edf4
3 years ago

So it's actually a workaround for rare corner cases which happen in some infrastructure. And it would allow me to install some obsolete policy without using rpm -i --nodeps as all new DSP packages would just require selinux-policy without version.

In the commit message, I miss an explanation for why you are making this change. You talk about new problems that this introduces, but not about the problem that you're trying to solve in the first place.

The first paragraph actually describes the current state -- i.e. the problem I'm trying to solve.
I'll try to rewrite it so that it's easier to understand.

Oh, right, sorry, somehow I thought that this PR adds the dependency, but it's already there and you're just changing it to a weak dep... I should have at least looked at the diff before commenting :)

So it's actually a workaround for rare corner cases which happen in some infrastructure. And it would allow me to install some obsolete policy without using rpm -i --nodeps as all new DSP packages would just require selinux-policy without version.

Only by using "--setopt=install_weak_deps=False". Otherwise the "Recommends" statement should ensure that the correct version of selinux-policy is installed.

Build failed.

@vmojzis, what is the current status of this PR - is it considered a viable solution to some of the dependency problems? If yes, please rebase it.

[citest]

rebased onto 615bd23fab6bf0a5283b4294037d73486aff9ee8
2 years ago

rebased onto 9c06a68ffe30e4a0d85269e7050c9b18b01c9e22
2 years ago

Unable to freeze job graph: Unable to modify final job <Job rpm-sti-test branches: {MatchAny:{BranchMatcher:rawhide},{BranchMatcher:main}} source: fedora-project-config/zuul.d/_jobs-base.yaml@master#3> attribute timeout=21600 with variant <Job rpm-sti-test branches: None source: fedora-zuul-jobs-config/zuul.d/projects.yaml@master#108>

@vmojzis, what is the current status of this PR - is it considered a viable solution to some of the dependency problems? If yes, please rebase it.

I believe it does. In my mind it is better to have dnf install an older version of selinux-policy, which in most cases should work just fine with the DSP package, instead of blocking installation of the DSP package altogether (until the new selinux-policy package is available).

rebased onto 92f26746339f3c8e9ba8febde4778ee9a6013fcb
9 months ago

So it's actually a workaround for rare corner cases which happen in some infrastructure. And it would allow me to install some obsolete policy without using rpm -i --nodeps as all new DSP packages would just require selinux-policy without version.

Update after today's mtg with keylime: it is a workaround for corner cases, happening when a newer selinux-policy package is available in buildroot than it is later in some testing environment, and this effects in installing older version of the other component. It probably happens (only?) in an async z-stream build when the process was done in haste.

The current consent is selinux-policy maintainers will change Requires: manually at the beginning of a minor release development and the other component maintainers adjust it when needed, e. g. when a new permission/type/boolean/port is used.

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/e6939b4582184435a624a3f24848355a

rebased onto 1649df0
9 months ago

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/0a10ec6d54a644bea524b694e8cc24e6

Current state: still in development. Do not merge.

So apparently this behavior is broken in dnf4 (known issue) and will probably not be addressed. It may be fixed in dnf5.
https://github.com/rpm-software-management/dnf/issues/1868
https://bugzilla.redhat.com/show_bug.cgi?id=2057979

For now it is broken in dnf5 as well.
https://github.com/rpm-software-management/dnf5/issues/1073
Changes Summary 1
+5 -2
file changed
rpm.macros
Powered by Pagure 5.13.3
Documentation • File an Issue • About this Instance • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.