I think this is related to an issue where the owner property of a file is not set until after the resource is created. So when ACLSecurityImpl checks an inherited "owner has write" permission, no one is the owner yet.
i think the problem is one step before that. when ACLSecurityImpl tries to retrieve the revision descriptor for the resource, which happens before checking the resource's owner, an exception is thrown since the resource hasn't yet been created.
perhaps i don't understand the permission inheritance model, but my expectation was that if the owner has an inherited write permission on the parent collection, he would automatically have permission to write any resources within the collection. that doesn't seem to be the wa things work tho :)
It seems like a simple bug, but I haven't come up with a good way to fix the design, so it would probably have to be a special case in the code (and I think that's just ugly). Also, I think owner-only write permissions aren't very common, so no one's gotten itchy enough yet to scratch at it.
yeah, i'm not really sure what to do about it. i don't have enough a feeling for the design of this component (or for Slide's security framework in general) to propose a solution without a lot more study.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
