The concern is not with the users and I don't want to have to authenticate a user every time they request a file. It sounds like if I read the Guarded file How to correctly; thats what will occur after installing and using a GuardedFile.
Authentication is done by Zope for every request made. It's just the nature of the beast. (And it doesn't have a significantly high computational overhead.) You, as developer, really shouldn't have very much to do with it; if you do, you're working too hard. Set the permissions on the objects and code such that links display only if permissions are available. (In a loop, this is 'skip_unauthorized'.) Your users log in, and are presented only with links to objects to which they have access. When they try a download, Zope checks their permissions and serves up the content if everything clicks. You can even do this with your "views". This is not to say that you don't have some strage requirements or that it would be an easy retrofit, of course.
The main concern is with our contracted Web Server Admins. Even if I were to set up roles and security for our contractors they could still migrate data.fs to a new ZOPE server set up an emergency user account and access the ACL Users Folder. Correct? This is the assumption I am working on.
If you have something for which this is a valid problem, the only real solution is to get admins you can trust. There's almost no way to secure yourself against God, and that's what a sysadmin is to his computer. You have two possible other avenues: 1) encrypt sensitive data before you store it in the ZODB, either client or server side. Then decrypt on the client side, because if you decrypt in software that can be hijacked (and you're right, it's easy enough to jack Zope if you have filesystem access to it) you're wasting your time. And if you have clients like mine, they don't want to deal with decrypting things. 2) don't allow your sysadmins to be root. Someone you trust is root, and your hired admins are almost root. Restrict the ZODB from everyone but the Zope user and root, and don't let your almost-root admins su to that user. And if untrusted people have physical access to your machine, you should put it on an encypted filesystem, too. A lot of sysadmins would balk at this, and you have to end up with a sysadmin on staff, at least part-time, which presumably you were trying to avoid in the first place. Even if you do one of these, or even both, it's still a dicey proposition whether you'll actually be able to keep out an attacker in such a priveledged position: you'll have to defend against single-user mode, local root exploits, tainted software, and other problems. (Approach #1 is pretty strong, but not foolproof. Both together are better, but only in that it'll take longer and require more diverse skills.) Frankly, there's no good way around an admin you don't trust. Although I'd love to hear some creative suggestions. --jcc