Bug#926096: radsecproxy: Upgrade aborts if radsecproxy.conf already exists with different owner

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#926096: radsecproxy: Upgrade aborts if radsecproxy.conf already exists with different owner

Jorge Daniel Sequeira Matias-2
Package: radsecproxy
Version: 1.7.2-1
Severity: normal
Tags: d-i



-- System Information:
Debian Release: 7.11
  APT prefers oldoldstable
  APT policy: (650, 'oldoldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages radsecproxy depends on:
ii  adduser      3.113+nmu3
ii  libc6        2.13-38+deb7u12
ii  libnettle4   2.4-3+deb7u1
ii  libssl1.0.0  1.0.1t-1+deb7u4
ii  lsb-base     4.1+Debian8+deb7u1

radsecproxy recommends no packages.

radsecproxy suggests no packages.

-- Configuration Files:
/etc/radsecproxy.conf changed [not included]

-- no debconf information

Despite the fact I have tested this package doing a backport for Debian "wheezy" the package upgrade operation aborts even the installer replaced /etc/radsecproxy.conf.
This is due to the fact that if the config already exists it has owner/group "root:root" because the upgrade is from version 1.6.9. And this ownership is not updated before starting the service.

Reply | Threaded
Open this post in threaded view
|

Bug#926096: radsecproxy: Upgrade aborts if radsecproxy.conf already exists with different owner

Sven Hartge-5
On Sun, 31 Mar 2019 14:10:10 +0100 Jorge Daniel Sequeira Matias
> Despite the fact I have tested this package doing a backport for Debian "wheezy" the package upgrade operation aborts even the installer replaced /etc/radsecproxy.conf.
> This is due to the fact that if the config already exists it has owner/group "root:root" because the upgrade is from version 1.6.9. And this ownership is not updated before starting the service.

Hello Jorge,

I think this bug is invalid and not a problem of the package but of a
non-standard setup on your part.

To reproduce this bug, I need to do the following things:

On Stretch:

1) create a new user, for example "radsec:radsec". The name needs to be
different than the user introduced in Buster "radsecproxy"
2) change the owner and group of /etc/radsecproxy.conf to that radsec:radsec
3) remove the permissions for other: chmod 640 /etc/radsecproxy.conf
4) Edit the Init-Script or systemd.unit to start radsecproxy as that user

Step 3 and 4 are crucial here.

Then, and only then, do I get an error during the upgrade to Buster
where radsecproxy won't start because it can't read the configuration file.

As long as the configuration file is world-readable, the upgrade works.

It is not possible for any package to anticipate any and every way an
administrator may have changed or altered the setup in the past and
correct it automatically on package installation or upgrade.

Grüße,
Sven.


signature.asc (849 bytes) Download Attachment