SELinux-Refpolicy Archive on
 help / color / Atom feed
From: Topi Miettinen <>
To: Russell Coker <>,
	Dominick Grift <>
Cc: Chris PeBenito <>,
	refpolicy <>
Subject: Re: [RFC] Purging dead modules
Date: Tue, 12 Jan 2021 01:52:39 +0200
Message-ID: <> (raw)
In-Reply-To: <3283555.42QHSe7XtN@liv>

On 11.1.2021 17.48, Russell Coker wrote:
> On Tuesday, 12 January 2021 2:23:47 AM AEDT Dominick Grift wrote:
>>> I'm looking to remove modules for dead programs, such as hal and
>>> consolekit. The question is how long to keep modules for dead
>>> programs?  I'm thinking something like 3-5 years.
>> Agree
> I think we should drop them when the programs aren't in the latest DEVELOPMENT
> versions of Fedora, Debian, or any other distribution that supports SE Linux.

I think this could be automated. If no file contexts in a module match 
any files in a list of all files of all packages of the selected distros 
concatenated, the module is probably obsolete (which could be also 
verified by looking at old releases) or it's for 3rd party software 
(never found in earlier distro releases). I tried to do this locally to 
disable unused modules, but it took way too long time with shell 
scripts. I suppose with a database or other proper tools it would be 

> The new policy will only be used by new versions of those distributions.
> Running a newer version of policy on an older version will not provide any
> benefits and in some cases won't work properly.  People should NOT expect the
> Git refpolicy to work well on Debian/Buster, if they try it they shouldn't
> expect much help from me.  While I have a general aim that you should be able
> to upgrade kernel, SE Linux policy (and things that get dragged in with it
> like libc), and applications separately this isn't a guarantee.  If Debian/
> Unstable doesn't include a daemon then I have no interest in supporting that
> daemon with SE Linux policy in Debian/Unstable.  People can migrate their
> configuration to the replacement daemon as part of the process of upgrading SE
> Linux policy.

As a Debian user, I've actually found that upstream refpolicy works 
somewhat better (as in less need to fix things by adding local rules) 
for unstable and especially when I'm building software myself directly 
from upstream, which may need the latest policy to work. Of course 
developing the reference policy is also easier when using upstream master.


  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11 14:48 Chris PeBenito
2021-01-11 15:23 ` Dominick Grift
2021-01-11 15:48   ` Russell Coker
2021-01-11 23:52     ` Topi Miettinen [this message]
2021-01-13 13:21       ` Chris PeBenito
2021-01-13 13:33         ` Dominick Grift
2021-01-19 15:11           ` Chris PeBenito

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

SELinux-Refpolicy Archive on

Archives are clonable:
	git clone --mirror selinux-refpolicy/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux-refpolicy selinux-refpolicy/ \
	public-inbox-index selinux-refpolicy

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone