Bug#881871: [pkg-bacula-devel] Bug#881871: stretch-pu: package bacula/7.4.4+dfsg-6

[Sven Hartge]

On 30.03.2018 18:03, Julien Cristau wrote:
> On Sun, Mar  4, 2018 at 11:08:00 +0100, Carsten Leonhardt wrote:
> 
>> Control: tags -1 - moreinfo
>>
>> "Adam D. Barratt"  writes:
>>
>>> -   --oknodo --exec $DAEMON --chuid $BUSER:$BGROUP -- -c $CONFIG
>>> +   --oknodo --exec $DAEMON -- -g $BUSER -g $BGROUP -c $CONFIG
>>>
>>> The first of those "-g" is presumably supposed to be "-u". I realise
>>> this may seem a small point, but it does make me wonder how it wasn't
>>> caught in testing.
>>
>> Thank you for your work and for catching this. A new version of the
>> patch is attached.
>>
> This leaves open the question of how much was this tested.  Can you
> describe what has or hasn't been done there?

I tested the proposed packages in a SysV-Init-based Debian Stretch VM. I
can confirm every daemon runs as the user and group it is supposed to
run as.

root@debian-stretch:~# ps auwwx | grep [b]acula
root  5101  0.0  0.2  66988  5512 ?Ssl  21:16   0:00
/usr/sbin/bacula-fd -u root -g root -c /etc/bacula/bacula-fd.conf
bacula5175  0.0  0.2 130420  5384 ?Ssl  21:16   0:00
/usr/sbin/bacula-sd -u bacula -g tape -c /etc/bacula/bacula-sd.conf
bacula5403  0.0  0.3  74728  6628 ?Ssl  21:20   0:00
/usr/sbin/bacula-dir -u bacula -g bacula -c /etc/bacula/bacula-dir.conf

root@debian-stretch:~# ps -eo pid,comm,euser,supgrp | grep [b]acula
 5101 bacula-fd   root root
 5175 bacula-sd   bacula   tape
 5403 bacula-dir  bacula   tape,bacula

I also checked why I did not notice the problem Adam spotted in the
first place. I can only guess this happened because bacula-dir fell back
to running as "root" when no "-u bacula" was specified, which made all
my tests work as they should (because root has obviously no restrictions).

The reason for this fallback is the Debian package does not specify a
runtime user at build time. This was done in the past so that the
runtime user can be chosen by the admin of the system.

But since then we changed the packaging and got rid of this ability
because in reality nobody was doing this anyway and it complicated the
packaging.

If the runtime user were set during package build, this problem would
not have occurred because the parameters -u and -g wouldn't be needed in
the first place.

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#881871: [pkg-bacula-devel] Bug#881871: stretch-pu: package bacula/7.4.4+dfsg-6

[Sven Hartge]

On 03.03.2018 14:34, Adam D. Barratt wrote:
> On Mon, 2018-02-26 at 13:14 +0100, Carsten Leonhardt wrote:

>> here is a new version of the patch. I now additionally let
>> bacula-common.preinst check for the existence of
>> bacula-director-common.postrm and comment out the offending line if
>> found (first chunk in the diff). I chose to use bacula-common because
>> it
>> is depended upon by all other bacula packages.
>>
>> I've also amended the text in the changelog, otherwise the rest of
>> the
>> patch is the same as the previous version.
> 
> - --oknodo --exec $DAEMON --chuid $BUSER:$BGROUP -- -c $CONFIG
> + --oknodo --exec $DAEMON -- -g $BUSER -g $BGROUP -c $CONFIG
> 
> The first of those "-g" is presumably supposed to be "-u". I realise
> this may seem a small point, but it does make me wonder how it wasn't
> caught in testing.

This is embarrassing. You are of course right. I am sorry. Must have
been a copy'n'waste error on my part.

I'll prepare a fix for Sid and Stretch at once.

As why this has not been caught during testing I need to investigate. I
have a suspicion but I need to confirm it first.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#881871: [pkg-bacula-devel] Bug#881871: stretch-pu: package bacula/7.4.4+dfsg-6

[Sven Hartge]

On 03.03.2018 15:17, Sven Hartge wrote:
> On 03.03.2018 14:34, Adam D. Barratt wrote:

>> The first of those "-g" is presumably supposed to be "-u". I realise
>> this may seem a small point, but it does make me wonder how it wasn't
>> caught in testing.
> 
> This is embarrassing. You are of course right. I am sorry. Must have
> been a copy'n'waste error on my part.
> 
> I'll prepare a fix for Sid and Stretch at once.

I have pushed a fix to the master and stretch branches.

> As why this has not been caught during testing I need to investigate. I
> have a suspicion but I need to confirm it first.

My suspicion was not true, but it shows an error in my testing
procedure. It seems I only tested the systemd path and not the SysV-init
one.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature