Hi!
if Data.fs is owned by nobody.nogroup, Apache is installed on the same machine, and the user can run his own cgi-scripts (most ISPs I suppose), then by default the user's CGI scripts will run as nobody too, allowing him to read Data.fs during his own CGI execution, and copy it wherever he wants during this time.
This is indeed the only really frightening scenario. Finally a reason to not use "nobody" but a dedicated Zope user to run a Zope instance ;-)
Solutions:
* make Data.fs and Data.fs.old only readable by a user every other user on the system can't run commands as.
yep
* But the best to do is:
Encrypt all passwords in the ZODB.
And then I copy the Data.fs to a new Zope, create a superuser and walk in ... Or did I miss something? First of all, I don't think the password issue really IS an issue. I mean, as soon as I have read access to an Apache's data directory, I also can copy it. You just should not be able to come that far ... AFAIK there already exist patches for encrypted passwords, and alternative user folder implementations do it, too. Second, IF you want to make ZODB really secure, you would have to encrypt all of it, e.g. using a plugin similar to the compressed storage plugin, only doing encryption instead of compression, or doing the same thing on the OS layer with a loopback encrypted filesystem. However, in most cases this seems to be a bit too paranoid ... Joachim