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

[Carsten Leonhardt]

>> 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.

>> 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".

> 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.

>> Maybe a debconf question with a priority below default, defaulting to
>> running as root. This would allow for preseeding.
>
>> In my eyes, this is sufficient to close the wontfix-bug.
>
> Yes, I think so too. But I have _no_ idea how to do that. I can draft
> the things the code will have to do (mainly for systemd integration) but
> no knowledge whatsoever on how to do it.

If you want to go ahead:

http://www.fifi.org/doc/debconf-doc/tutorial.html

But I can take care of it too.

 - Carsten