Okay, this did the trick, but I'm not very happy with the result :-(
I don't want the DisplayClass to be acquiring and I don't really see (from a moral standpoint ;-) why I should need to mix in an Acquisiton class to make security work :-S
I suspect that was a rhetorical question, but ill answer anyway. Zope security is context based: Users can be defined in a subfolder and only have access under that folder, they can also be given local roles for a given folder. The role:permission mapping is set per-folder. Any security aware object needs to know its context.
That said, I think Shane said that Zope security is predicated a lot on Acquisition. Now, can I get the solution I'm looking for by mixing in Aquisition.Explicit, still have the security stuff work and not have the DisplayClass acquiring attributes I don't want it do?
Yes, you will need to set Acquisition.Acquired for the necessary attributes. Alternatively there may be other ways of avoiding an object using some specific acquired attributes: I often define an index_html=None to avoid a class using its container's default view. Wanting to make an object non-acquiring may be a danger-sign of some other problems. If the correctness of your program depends on the absence of certain attributes (acquired or otherwise) then you need to take extra care over PropertyManager-like features, which might allow a user to add the critical attribute. hth,