On Thursday 01 December 2005 15:28, Tomas Vasko wrote:
> Hi all;
>
> > > I do fully understand that file lists are specified on Director, but i
> > > would like to have a possibility to enumerate directories on FD that
> > > could be accessed by fd process and thus backed up. All directories
> > > that are not subdirectories of these specified would fd process refuse
> > > to backup and would return a kind of EPERM error to the director.
> > >
> > > Is it now more clear?
> >
> > Yes, thanks for clarifying it. I don't have any immediate plans to
> > implement this since the basic phylosophy of Bacula is that the Director
> > should decide on everything.
>
> IMHO, this is not against this philosophy, it just adds some security to
> the FD. Director still decides what and when to backup, but FD could have a
> right to disallow to backup some data which its administrator does not want
> be backed up (to the computer out of his control).
>
> My first proposal -- the returning the EPERM like error could also be
> extend for at least two cases -- in one the EPERM would be returned and in
> second one FD would either pretend that disallowed directories are empty,
> or they just don't exist. This would add a certain level of flexibility to
> FD on deciding which subset of backed up fileset shall be backed up
> actually. For example -- in Director would be fileset containing just /
> specified and on FD an administrator could anytime exclude any (big)
> directory that does not need to be backed up like /mnt/200GB_usbdisk
>
> > However, you may be interested in using data encryption that Landon is
> > working
>
> Yes, definitely i am, I've already voted for that with highest priority :)
>
> > on. In this project, the FD can require encryption to be enabled, and
> > hence you can from your Client machine guarantee that no one else can
> > read your data. This isn't exactly what you asked for, but would still
> > allow protection of your private directories.
>
> thanks for the hint, i know and i do plan to use it this way, but is many
> cases it is not necessary to hog cpu by encryption and add another point of
> failure (possible implementation error, (decryption)key loss,...) and at
> the same time the possibility of disallowing access to private parts is
> inevitable or at least highly desired.
>
> BTW, FD's right to refuse to backup data without encryption seems to be the
> same level of "violation" of the 'director should decide on everything'
> philosophy as the refusal of backing up some directories ;) Or am I wrong?
I don't see how you can make the FD refuse backing up some directories without
adding code into the FD that knows about what directories and files should be
backed up. That implies decentralizing the backup decision. Your case seems
to me to be rather special in that you do not trust the Bacula administrator.
Solving that problem is something that is a priority at this stage -- perhaps
some day.
Also, the suggestion made by a user to run the FD as non-root and perhaps use
groups, could help resolve some of your concerns.
>
>
> bye,
> tomas
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
