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

[Sven Hartge]

On 30.08.2016 09:46, Carsten Leonhardt wrote:
>>> I still think that bacula-fd should run as root by default, as restores
>>> will not work correctly otherwise.
>>
>> They will work partly, because the default restore path is
>> /tmp/bacula-restores, which is writeable by user bacula.
>>
>> The restored files will not have the correct user and possibly wrong
>> ACLs though.
> 
> When you need a restore urgently, you shouldn't get extra surprises. I
> consider correct ownership and permissions as an integral part of the
> data. That's why I wouldn't want the default to be to have a crippled
> restore.

Yes, I agree. I changed the default back to the normal root-running mode
and documented the problems you face if you run as non-root.

>>> Those that know what they do can then switch to running it as non-root
>> (probably nobody.nogroup).
>>
>> I don't think using nobody.nogroup for too much is a good idea. Besides
>> it will also complicate the permissions for the configuration in
>> /etc/bacula. They will have to be readable by "nobody", giving every
>> other daemon running as that user full access to the bacula-fd
>> configuration.
> 
> It can read everything because of the capabilities :-) But ok, a
> separate user would be better instead of "nobody".

"_baculafd"?

>> I see no harm in using the existing user bacula for this purpose.
> 
> bacula-fd would have write access to all files owned by bacula,
> including a possible backup storage when bacula-fd and bacula-sd run on
> the same machine. Those that would like to go the extra mile and not run
> bacula-fd as root might have a problem with that.

OK, makes sense.

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/d7de1381/attachment-0001.sig>