[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