Bug#924312: stunnel4: Fails to stop with sysvinit: start-stop-daemon: matching only on non-root pidfile /var/lib/stunnel4///stunnel4.pid is insecure

--CGDBiGfvSTbxKZlW
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 11, 2019 at 09:28:04PM +0100, Axel Beckert wrote:
> Control: reassign -1 lsb-base
> Control: forcemerge 921558 -1
> Control: affects 921558 + stunnel4
>=20
> Hi Paul,
>=20
> Paul Gevers wrote:
> > On Mon, 11 Mar 2019 14:15:25 +0100 Axel Beckert <[email protected]> wrote:
> > > Version: 3:5.50-3
> >=20
> > ^^^^^^^^^^^^^^^^^^^
> > I don't think the bug is only in this version, is it?
>=20
> No. But for a reason I did not expect:
>=20
> In contrary to the other cases of this issue I run into recently
> (miredo and smokeping), stunnel4's init script doesn't use
> start-stop-daemon directly but via killproc() from
> /lib/lsb/init-functions of lsb-base. And the actual bug seems to be in
> that shell script library:
>=20
>     125 # start-stop-daemon uses the same algorithm as "pidofproc" above.
>     126 killproc () {
>     127     local pidfile sig status base name_param is_term_sig OPTIND
>     128     pidfile=3D
>     129     name_param=3D
>     130     is_term_sig=3D
>     131=20
>     132     OPTIND=3D1
>     133     while getopts p: opt ; do
>     134         case "$opt" in
>     135             p)  pidfile=3D"$OPTARG";;
>     136         esac
>     137     done
>     138     shift $(($OPTIND - 1))
>     139=20
>     140     base=3D${1##*/}
>     141     if [ ! $pidfile ]; then
>     142         name_param=3D"--name $base --pidfile /var/run/$base.pid"
>     143     else
>     144         name_param=3D"--pidfile $pidfile"
>     145     fi
>     [=E2=80=A6]     [=E2=80=A6]
>     152     status=3D0
>     153     if [ ! "$is_term_sig" ]; then
>     154         if [ -n "$sig" ]; then
>     155             /sbin/start-stop-daemon --stop --signal "$sig" \
>     156                 --quiet $name_param || status=3D"$?"
>     157         else
>     158             /sbin/start-stop-daemon --stop \
>     159                 --retry 5 \
>     160                 --quiet $name_param || status=3D"$?"
>     161         fi
>     162     else
>     163         /sbin/start-stop-daemon --stop --quiet \
>     164             --oknodo $name_param || status=3D"$?"
>     165     fi
>=20
> Since neither name_param nor any of the start-stop-daemon --stop calls
> contain --exec or -x nor does killproc allow to pass additional
> parameters, this looks like a bug in lsb-base. And indeed, it is and
> is also already reported: https://bugs.debian.org/921558
>=20
> Reassigning accordingly.

Thanks for reporting this and for your analysis!  I came up with the
same result (didn't reply since I was still going through the Git log to
see in which version of stunnel the use of killproc was introduced) and
I have a patch for stunnel4 now that uses start-stop-daemon directly,
although this would be a divergence from the upstream source - the
upstream author switched to the LSB killproc several years ago after
seeing that I had made that change in Debian... so it would be a pity
to now say "well, yeah, but you see, it doesn't really work, so let's go
back to looking for the list of processes and sending the signals by
ourselves" :)

To be honest, I don't think I should upload stunnel with a patch that
makes the init script use the LSB start_daemon function to start
the process and then uses start-stop-daemon directly to stop it;
I might make another change that uses start-stop-daemon in both places,
but, honestly, I would prefer some kind of change in init-functions that
would let me continue to use the LSB shell functions.  Even if it means
passing an additional argument to killproc to make it use --exec, this
would still be an acceptable divergence from upstream for me.

> > This bug is currently blocking the migration of stunnel4 to testing
> > which is needed to have openssl migrate. I'd like to do that today
> > because tomorrow the full freeze starts.
>=20
> Should be solved now. Thanks for poking me so that I had a closer
> look!

Thanks to both of you for raising this and noting its importance!

G'luck,
Peter

--=20
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} [email protected]
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

--CGDBiGfvSTbxKZlW
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAlyGyj4ACgkQZR7vsCUn
3xOQOg/+IMMQ8hNI6yRfAIRij3b07XnbsvwQmbZlUBrqLOnXsq1IzOxdC4AmhSXo
eR6hIJpeXh+nbCPIujgcvrnhJNWM57yJ1p+32jc7UUno2QEw/KNYR4ly/llotQkf
0BY0sgusXDS2mxy+mcd8RF7+o9flIQtew5QpjKC7TYNJmKDpFeuq4zm3/q213CTz
+Fw8hXFvGq4nFMB1Dqz4dIiRs4YImZ1DZMvIcRGaWs5GmdEpPnYHIcXYkTHFZ4xy
0513w7/wG7ge5Bc3n8fn57NyJCOVoe9pb8eHhJJRJ/egcP+YRsqL+iUc/rO4kamQ
sCiDA282HFU3N7KELsDGPo/q2Dm3ITk4Wo6yaCKrKAtm7OwkVRRD+cthsfDlNjVJ
wm+KNWInqP9DMsXf5QqJPQaH/6h+o+AqVaUSLQMU1hSaombpEFsiMHqAkNcCLyyX
1TsTqVfJniQG3XyBkQfdnxuQJh1oeyHg3O2vVs+4eyH46Qs8eFAoz91p7JhP9USY
I3AdGd+oMQU8xJpcDws1gmPzKzmNCIrzw59j1WBg7c0kzLHN66h1IQuDZ3UM4d1r
9BFwcCQoj7PUSrg5oOByyc6EVphli5m4bKhDQXV4nLSVDQakptR4bICPY1V2rJBi
ynDmNp2OAeltp5bDWYFcjMEh5jOCJVmgUK9+O3iN6fxgFkTTeA0=
=ybpT
-----END PGP SIGNATURE-----

--CGDBiGfvSTbxKZlW--