[pkg-bacula-devel] bacula-fd dropping privileges

[Sven Hartge]

On 31.08.2016 11:18, Carsten Leonhardt wrote:

>> 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.
> 
> I think that running dpkg-reconfigure triggers the postinst configure,
> but I'm not sure. So the recommended way to change could be
> "dpkg-reconfigure -plow bacula-fd". If the necessary program isn't
> installed, another note could be shown, informing the user that
> libcap2-bin is missing and that they should re-run dpkg-reconfigure
> after installing it.
> 
> Reading the policy section again, I'd say Suggests corresponds best.
> 
>> 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.
> 
> I'd guess that the procedure I've outlined above would be sufficient.
> 
>> All in all it boils down to: how much granular choice do we allow the
>> user in this matter?
> 
> If I understand correctly, we have a choice here between handling the
> setting of capabilities ourselves and having automatic backtraces, or
> letting bacula-fd handle it itself (-k -u -g), but probably not have working
> backtraces anymore, right?

For bacula-fd, right. The two other daemons have fixed non-root users
and don't need capabilities to run as non-root.

> We could also say that, until it's fixed upstream, there aren't
> automatic backtraces if using capabilities. That would make everything
> much simpler, no? Just ask about dropping capabilities and set "-k"
> accordingly.

As I understand the problem, there is nothing upstream can fix. If a
process drops privileges itself, it can't ptrace itself anymore:
http://www.bacula.org/git/cgit.cgi/bacula/commit/?h=Branch-7.4&id=3924012940114148be0ef565e6d979597f9a27d1

Using "-u user -g user" prevents this for any daemon.

This is why I changed the init-script and systemd-unit to use
start-stop-daemon/systemd to change the UID of the process before
starting the daemon.

This does not work for bacula-fd, because of "-k".

So, yes, we can either use capabilites in filesystem to run bacula-fd as
non-root and retain the possibility for automatic backtraces _or_ we let
bacula-fd set the process capabilites internally (via -k) before
chuid()ing itself, but lose automatic backtraces for bacula-fd.

(And this is exactly the problem I wanted to bring to the attention of
Kern.)

The second one would be simpler to implement, because we basically have
to do nothing to implement it because everything is already in place.

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/20160831/828a286c/attachment.sig>