Devuan bug report logs - #881
invoke-rc.d: Policy layer may override runlevel constraint

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):

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

Message #8 received at 881@bugs.devuan.org (full text, mbox, reply):

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

Message #15 received at 881@bugs.devuan.org (full text, mbox, reply):

On Tue, Apr 1, 2025 at 6:23 PM Mark Hindley <mark@hindley.org.uk> wrote:
> 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?

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.

> It is worth reading https://bugs.debian.org/911290 which gives some useful
> 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

Message #20 received at 881@bugs.devuan.org (full text, mbox, reply):

Hello Opty,

On Wed, 2 Apr 2025 13:54:05 +0200
Opty <opty77@gmail.com> wrote:

> On Tue, Apr 1, 2025 at 6:23 PM Mark Hindley <mark@hindley.org.uk>
> wrote:
> > 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?
> 
> 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'.

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


> 
> (*) 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.
> 
> > It is worth reading https://bugs.debian.org/911290 which gives some
> > useful 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
> _______________________________________________
> devuan-dev internal mailing list
> devuan-dev@lists.dyne.org
> Manage your subscription:
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
> Archive: https://lists.dyne.org/lurker/list/devuan-dev.en.html

Message #25 received at 881@bugs.devuan.org (full text, mbox, reply):

On Wed, Apr 2, 2025 at 2:33 PM Lorenzo <plorenzo@disroot.org> wrote:
> 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.

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

Message #30 received at 881@bugs.devuan.org (full text, mbox, reply):

On Wed, Apr 02, 2025 at 01:54:05PM +0200, Opty wrote:
> On Tue, Apr 1, 2025 at 6:23 PM Mark Hindley <mark@hindley.org.uk> wrote:
> > 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?
> 
> Hopefully the whole story so far:
> 
> 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

Message #43 received at 881@bugs.devuan.org (full text, mbox, reply):

On Wed, Apr 2, 2025 at 6:07 PM Mark Hindley <mark@hindley.org.uk> wrote:
> On Wed, Apr 02, 2025 at 01:54:05PM +0200, Opty wrote:
> > Hopefully the whole story so far:
> >
> > 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).

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

Message #48 received at 881@bugs.devuan.org (full text, mbox, reply):

On Wed, Apr 02, 2025 at 11:27:15PM +0200, Opty wrote:
> 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.

That isn't conventional Debian practice.

> > 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.

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

Message #53 received at 881@bugs.devuan.org (full text, mbox, reply):

On Thu, Apr 3, 2025 at 8:46 AM Mark Hindley <mark@hindley.org.uk> wrote:
> On Wed, Apr 02, 2025 at 11:27:15PM +0200, Opty wrote:
> > 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.
>
> 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.

> > > 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.
>
> 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.

Maybe dh_installinit could support conditional start based on
environment variable.

Regards,
Opty

Send a report that this bug log contains spam.