Re: [PATCH v5] libsepol: drop support for policy versions before xperms_ioctl/xen_devicetree

[Russell Coker <russell@coker.com.au>]

On Tuesday, 1 September 2026 04:01:05 AEST Stephen Smalley wrote:
> This would break e.g. RHEL 7, Debian 9, Ubuntu 16.04, or SUSE/SLES 12
> if they ever updated to a version of libsepol with this change but I
> think that's unlikely.

I have no interest in Debian 9.  If someone wants to update a Debian 9 system 
to a current version of libsepol I'm not bothered if it breaks totally.

> The greater risk is if you have any lingering binary modules compiled
> with versions < 18 inherited across multiple upgrades (e.g. RHEL-7 to
> RHEL-8), then those modules will break and probably in a not-very-nice
> way (libsepol suddenly won't be able to parse them and therefore any
> semodule/semanage operations will fail and you might have to delete
> them manually from the policy module store).

Binary modules aren't something I'm interested in for Debian.  Just don't use 
modules unless you have the .te file.

> I'm fine with deferring this change to a future libsepol release after
> 3.12 (e.g. 3.13 or later) if that would be safer for the distros.

I don't think there's a reason to delay.

Also last I checked the current git refpolicy compiled with the recent 
libsepol etc causes a kernel panic on the Debian 13 kernels.  So if we don't 
get that fixed then the Debian 14 kernel will be required for any sort of new 
policy.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/