On 12 Feb 2006 at 14:07, Landon Fuller wrote: > Landon Fuller wrote: > > One other issue worth raising -- The director can currently overwrite > > any file on the FD, including the encryption keys or the FD > > configuration file, thus exposing private data to the director. > > Something else I forgot to mention; the file daemon also ensures data > integrity by signing each file. Currently, only file data is signed -- > permissions, ownership, et al are not.
Signing it is nice. Does any signature verification occur? e.g. the SD as it receives the data during backup? Before SD sends during restore? When the FD receives during restore? > AFAIK, during a restore, the storage daemon will provide the stream > data in the same order it was written by the file daemon. If that's > true, the easiest way to add extra file attributes/streams to the > signature is to checksum them as we send them to (and receive them > from) the storage daemon. After checksum'ing them, what would you do with them? > Kern, is it reasonable to assume that the Storage Daemon will always > provide per-file stream data in the order it was written by the File > Daemon? If not, I'd guess the alternative is to cache the file > attributes on restore and checksum them in the standard order. What would happen if we received out-of-order packets? -- Dan Langille : Software Developer looking for work my resume: http://www.freebsddiary.org/dan_langille.php ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
