+-------[ bruno modulix ]---------------------- | Dieter Maurer wrote: | | Hi Dieter | | > bruno modulix wrote at 2005-9-27 11:34 +0200: | > | >>I have a little problem with aquisition and security. We have a project | >>using multiple CPS instances (for those that don't know CPS, it's a CMF | >>based groupware/CMS) running in the same Zope instance, and being | >>siblings of each others [1]. One of these instances is the main entry | >>point for the portal (I'll all it the 'portal'), the others are acting | >>as workspaces for dedicated communities (I'll call them CPMs). | >> | >>Each CPS instance has its own UserFolder. All users exists in the | >>portal's UserFolder, but only exists in some CPMs UserFolders. Now the | >>problem is that, due to acquisition, a member existing in the Portal but | >>not in a given CPM can gain access to this CPM by faking the url - ie: | >>going to mydomain.tld/portal/cpm instead of mydomain.tld/cpm. So we have | >>a potential (err...) security hole here, that I would like to address ASAP. | > | > | > Sounds like a permission to role mapping flaw... | > | > Apparently, roles controlled by the "Portal" UserFolder (e.g. | > "Authenticated") are allowed to do things in your CPM that | > you only be allowed by roles controlled by their UserFolder. | > | > You may be able to fix this by making the roles controlled | > by the "Portal" and the "CPM" level disjoint. | > | > "Authenticated" cannot be made disjoint -- but you may not use | > it inside your CPMs. | | The problem here is that CPS (the portal and all CPMs are CPS instances) | uses predefined roles, on which the various workflows relies, so that | would mean renaming all roles - differently - on each CPM, and modifying | the workflows too. Given that the customer is going to create new CPMs | "at will", I'm afraid this solution is somewhat unpractical... And turning off "Acquire" roles on the security tab of the folders you don't want to have acquired doesn't work? -- Andrew Milton akm@theinternet.com.au