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

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.  

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.

Distributions like Fedora have a stronger binding between policy and daemons 
than Debian does, and RHEL has an even stronger binding.

That said, Debian tends to keep daemons longer than most distributions.  If a 
daemon doesn't have known security issues and some people like using it then 
it stays in the archive.  When Debian keeps a daemon that loses support 
upstream your REALLY want good SE Linux policy for it!
> some suggestions:
> sectoolm, kdumpgui, kudzu, readahead, smoltclient, tmpreaper,
> firewallgui, gift, podsleuth, ptchown, sambagui, yam, hotplug, pcmcia,
> dnssectrigger, kerneloops, keyboardd, rhgb, roundup, speedtouch, w3c,
> xprint

kerneloops is still in Debian/Unstable and running on some of my Debian/
Unstable machines.

In Debian/Unstable /etc/init.d/ has type 
tmpreaper_exec_t, so this is still being used.  But I am up for a discussion 
about other ways of doing this.

My Main Blog
My Documents Blog

  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 [this message]
2021-01-11 23:52     ` Topi Miettinen
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 \
    --in-reply-to=3283555.42QHSe7XtN@liv \ \ \ \ \

* 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