On 7/1/2013 9:11 AM, Grant wrote: >>>> Bacula does have root read (and write) privileges on every backed-up >>>> system, >>>> but you can encrypt the backups before sending them to the central server. >>>> Bacula can also sign the backups, so the client can verify that a restore >>>> doesn't contain modified data. You still have to keep the >>>> encryption/signing >>>> keys secure of course. >>> Thanks for your help. I don't think I have the b*lls to give root >>> read/write on every system to the backup server. :) >>> >>> - Grant >> You are free to operate the FD (Client) with any permission you like, >> but you have to take care that the FD is able to read anything you >> like to backup and i case of restore it should be able to write and >> maybe to "chown" the files in question. > I may have misunderstood before. The FD runs on the client machines, > correct? Read and writing to localhost is no problem. What worries > me is one machine having root read(/write) permission on another > machine. Can bacula operate without that?
The Dir and the SD can have no greater permissions than what the FD is assigned. FD does not have to run as root. However, FD does have to have permissions sufficient to read/write the data that is to be backed up / restored. Data for which the FD has no access is safe even from a compromised Dir or SD. The Dir can be configured to run commands on the client. It cannot upload scripts to the client and execute them, but it can execute scripts/commands that already exist on the client. Again, the FD does not have to run as root and commands that the Dir runs on the client can only run with the FD's permissions. Of course, if you are worried about securing the data itself, (the data being backed up), then the permissions of the FD are irrelevant and you must use Bacula's data encryption. In this scenario the SD and Dir do not have the FD's private key and so cannot decrypt. Backups are stored encrypted and files are only ever decrypted by the FD on the client machine during a restore. The Dir and SD never see plaintext file data. Whether using Bacula or some other networked backup solution, the client's data MUST at some point be written to the media. PKI data encryption is therefore the only possible protection from a compromised network backup service like Bacula SD,/DIR. Fortunately, Bacula has built-in support for PKI data encryption. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
