-----Original Message----- From: Jonothan Farr [mailto:jfarr@real.com] Sent: Wednesday, October 27, 1999 04:13 To: kent@goathill.org Cc: zope Subject: Re: [Zope] [announce] Local File System product

...

...

What I was planning on doing for security was having an "access" file in the products directory that contained a list of directories and a list of the files (allowing wildcards) that you were allowed to access in _that_ directory. It was going to default to only letting you read txt and log files in the product directory itself (defined by .). You could also add roles to this file.

My 'file access' product creates Zope folders which correspond to directories and other interesting objects. These Zope folders can use the std zope acl_users (or whatever) and can also contain methods and products in the Zope database specific to that directory or file tree. This allows you to create different meta-data for the same directories, depending on how they are accessed from Zope (different subdir folders pointing at the same filesys path).

That's closer to how I was planning to allow access control for specific directories and files. The problem with this approach is that I don't want to make the objects that represent directories or files in the local file system persistent Zope objects, which would be necessary to store access control data in the ZODB. I like the 'access' file approach for that reason, but I don't like the fact that it wouldn't be manageable throught the Zope interface. I honestly haven't come up with a really good solution yet.

Solution: Make the files/folder persistant but every request checks for the existance of its filesystem counterpart. If its gone then it gets deleted. Slow but it would work.