Subject: invoke-rc.d: Policy layer may override runlevel constraint

From: Opty <[email-masked]>
Date: Tue, 1 Apr 2025 14:13:44 +0200

Package: init-system-helpers
Version: 1.65.2devuan1

querypolicy call in invoke-rc.d may override previous result of K link
test. When using permissive default policy this leads to e.g. unwanted
start of a disabled service after package upgrade.

Regards,
Opty

---

From: Mark Hindley <[email-masked]>
Date: Tue, 1 Apr 2025 17:23:50 +0100

Control: tags -1 moreinfo

Opty,

Thanks for this. However, I find your report a bit terse.

Do you have policy-rcd-declarative installed? If so what is usage for it? How do
you have a permissive policy defined?

It is worth reading https://bugs.debian.org/911290 which gives some useful
background as to why this area is a pretty unfrequented backwater.

Mark

---

From: Opty <[email-masked]>
Date: Wed, 2 Apr 2025 13:54:05 +0200

> you have a permissive policy defined?

Hopefully the whole story so far:

I wanted to disable services auto(re)start on package install/upgrade
so indeed I installed policy-rcd-declarative and
policy-rcd-declarative-deny-all which worked well for subsequent
vnstat install but then log rotation stopped working due to
invoke-rc.d so I modified 'deny' in /etc/service-policy.d/99-deny.pol
to 'allow' (*) but then K-link-disabled rsyslogd unexpectedly started
after an upgrade (**) so I had to surrender for now and 'chmod -x
/usr/sbin/policy-rc.d-declarative'.

(*) Yes, I should have installed policy-rcd-declarative-allow-all
instead but what if I needed to go back again so for now I chose this
maybe a bit confusing solution.

(**) I use own sysklogd package without dependencies so I can keep
rsyslog along and experiment.

> background as to why this area is a pretty unfrequented backwater.

I went through 911290 a week ago when I was doing my research.

Regards,
Opty

---

From: Lorenzo <[email-masked]>
Date: Wed, 2 Apr 2025 14:33:40 +0200

Hello Opty,

On Wed, 2 Apr 2025 13:54:05 +0200
Opty <[email-masked]> wrote:

> > Do you have policy-rcd-declarative installed? If so what is usage
> > for it? How do you have a permissive policy defined?
> 

I'm not sure what you want to do is supported by the
policy-rc.d-declarative, but maybe you can do that with the old
interface.

The policy-rc.d thing is meant to prevent signal (start stop
restart) to services in chroots where it does not make sense to
have a service running; for example, is used by the installer (but also
by sbuild and there are other use cases);
it could be also used by the local admin but the typical use is decide
to completely block the entire package machinery on a service.

I'm not sure how the declarative interface works, but the
service name and the action (start/restart/stop/reload/whatever)
are passed as argument to the old policy-rc.d script, so maybe with
some scripting you can block start/restart actions but allow reload
(or whatever is used by logrotate) ?

I suggest you try to play with it, an example
(it won't stop anything, just to understand how it works)

# cat /usr/sbin/policy-rc.d 
#!/bin/sh

echo "first param is $1" >> /run/policytest.txt
echo "second param is $2" >> /run/policytest.txt

# 0 or 104 = run
# 101 = do not run (denied by policy)

exit 0

then call invoke-rc.d servicename restart and inspect
/run/policytest.txt

Hope it helps,
Lorenzo

> > It is worth reading https://bugs.debian.org/911290 which gives some
> > useful background as to why this area is a pretty unfrequented
> > backwater.
> 
> _______________________________________________
> devuan-dev internal mailing list
> [email-masked]
> Manage your subscription:
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
> Archive: https://lists.dyne.org/lurker/list/devuan-dev.en.html

---

From: Opty <[email-masked]>
Date: Wed, 2 Apr 2025 15:41:39 +0200

> policy-rc.d-declarative, but maybe you can do that with the old

It would work perfectly for me if invoke-rc.d respected K links even
when policy layer allows an action.

I could modify invoke-rc.d just like that but I felt I should let you
know to make sure I'm not missing anything.

Regards,
Opty

---

From: Mark Hindley <[email-masked]>
Date: Wed, 2 Apr 2025 17:07:24 +0100

> I wanted to disable services auto(re)start on package install/upgrade

Why? The usual rationale is to *want* restart on upgrade so that the newly
installed version is actually running (with any security fixes that might
bring).

To start or not on install is specified in the package by the maintainer.

Mark

---

From: Opty <[email-masked]>
Date: Wed, 2 Apr 2025 23:27:15 +0200

> installed version is actually running (with any security fixes that might

You may want to upgrade ASAP but restart when convenient (e.g. during
low traffic at night) but maybe also a habit from Slackware in my
case.

> To start or not on install is specified in the package by the maintainer.

On our VPS I haven't found any which doesn't start service on package install.

Regards,
Opty

---

From: Mark Hindley <[email-masked]>
Date: Thu, 3 Apr 2025 07:46:55 +0100

> low traffic at night) but maybe also a habit from Slackware in my

That isn't conventional Debian practice.

> On our VPS I haven't found any which doesn't start service on package install.

It certainly isn't common. But, for example, look at src:netperf: d/rules has

override_dh_installinit:
	dh_installinit --no-enable --no-start

and the daemon is not started on install.

Mark

---

From: Opty <[email-masked]>
Date: Thu, 3 Apr 2025 13:16:40 +0200

> That isn't conventional Debian practice.

I could continue using the policy layer unmodified, selectively allow
what I need (extra work) and keep denied the rest

-or-

modify invoke-rc.d or rather policy-rc.d to check
$DPKG_MAINTSCRIPT_NAME (to detect preinst, postinst, prerm or postrm
script), crosscheck $DPKG_MAINTSCRIPT_PACKAGE vs. $INITSCRIPTID
(substring of each other) to allow calling other scripts and
eventually do nothing, maybe ask the administrator.

Both seem unintentional error- or side-effect-prone.

I could also just modify invoke-rc.d to skip the querypolicy call in
case of K link.

> and the daemon is not started on install.

Maybe dh_installinit could support conditional start based on
environment variable.

Regards,
Opty

---

From: Mark Hindley <[email-masked]>
Date: Sun, 6 Apr 2025 09:37:14 +0100

Opty,

Thanks,

> I could also just modify invoke-rc.d to skip the querypolicy call in

I find it hard to see an actionable bug here. I think invoke-rc.d and
policy-rcd-declarative* are behaving as advertised. Your requirements appear
different to what policy-rcd-declarative-deny-all provides. So, as Simon
suggested, you need to write your own policy script to meet your requirements.

Therefore I will close this.

If you think I have missed something, please feel free to reopen.

Thanks

Mark