[pkg-bacula-devel] [bacula] 01/01: Reworks runtime user usage for daemins

Sven Hartge sven at svenhartge.de
Tue Aug 30 18:03:56 UTC 2016


On 30.08.2016 14:53, Carsten Leonhardt wrote:
> Sven Hartge <sven at svenhartge.de> writes:
> 
>> The postinst of bacula-fd currently unconditionally sets the needed
>> capability if it is possible, but this should not have any negative
>> consquences. If bacula-fd runs as root, the existing capability is a
>> no-op and if it is running as a user it is needed.
> 
> Agreed.
> 
>> We could make this also dependent on the debconf answer but I think this
>> would be overkill.
> 
> If something comes up, we can still do that later.

Next question is: Depend or Recommend libcap2-bin?

Recommend will work without errors because of the setcap testing code I
stole from iputils-ping's postinst, omitting the setcap if no setcap is
available (also needed for FreeBSD).

But it means the user will have to manually set the right capabilities
later, if s/he decides to go non-root and libcap2-bin was not available
at install time. This will be documented, but we all know that users
seldom read the documentation.

Another question: Right now the init-script silently falls back to the
original root-mode if the capability checks fails, even if the user
specified ENABLE_NONROOT=true.

Should we warn in that case, should we abort?

And then is the question on how to do those quite elaborate checks for
systemd? I can call another ExecStartPre script but I'd rather not
over-complicate the matter.

All in all it boils down to: how much granular choice do we allow the
user in this matter?

S°


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-bacula-devel/attachments/20160830/d305eedf/attachment.sig>


More information about the pkg-bacula-devel mailing list