LoginManager patch considered harmful (was Re: can't add loginmanager below root) loginmanager below root)
At 09:21 PM 6/28/00 +0000, Ty Sarna wrote:
In article <39541FC1.A239BC5@digicool.com>, Shane Hathaway <shane@digicool.com> wrote:
Ok folks,
I thought I had made it clear that this problem has been solved. I have sent a patch to Ty (about two weeks ago) as well as made the change in
Sorry for the delay. I'm just now cacthing up on all my zope-related mail. I've applied this patch, and it will be in the release tonight. However, I am a bit concerned about what happens if _owner is deleted. For purposes of setuid code, we'd like to use the owner as the user to setuid to, but if we can't force it to be the right user, that could be a problem. This will definately need more thought.
I'm afraid I've confirmed Ty's fears. The LoginManager patch to fix the "can't add below root" problem creates a new issue: ownership of objects within the LoginManager. I will be asking Ty to make a re-release of 0.8.7 to unpatch part of the patch, but for now, here's a short synopsis of the problem and how to fix it. Shane's patch changes manage_addLoginManager to set ob._owner = UnownableOwner, which is good, because this ensures that AccessControl.Owned.Owned._deleteOwnershipAfterAdd() can del self._owner. (I think that Owned shouldn't be doing this this way, but as yet I don't have a good alternative to propose that DC implement.) The problem is that once this is done, the LoginManager is no longer "unowned". To fix this, add the line: _owner = UnownableOwner to the body of the LoginManager class. This will ensure that even after _deleteOwnershipAfterAdd(), the LoginManager will remain "unowned". After you have made this fix and restarted Zope, you may want to "un-own" any objects contained within your LoginManagers which might have been created with ownership. To do this, you should go to each page of each LoginManager's management interface and copy all objects, then paste them. Delete the originals, and rename the copies back to their old names. The copies will then be "unowned". You can verify this by checking each object's management interface: if it is unowned, it will have no "Ownership" tab. Why does LoginManager want its contents unowned? It has to do with the new security model. When an executable object is owned, the security machinery wants to validate that its owner is allowed to do whatever the executable is doing. This is great except for the fact that in many sites, the owner of the LoginManager's objects is actually a user that was retrieved from that LoginManager. This means that if LoginManager executes an object to find out information about a user, and that object is owned by a user from that LoginManager, infinite recursion and a core dump will swiftly follow. For this reason, you should make sure that all executable objects in a LoginManager are either unowned or owned by a user who is *not* supplied by that LoginManager. In practice, making sure they're unowned is usually easier.
"Phillip J. Eby" wrote:
Shane's patch changes manage_addLoginManager to set ob._owner = UnownableOwner, which is good, because this ensures that AccessControl.Owned.Owned._deleteOwnershipAfterAdd() can del self._owner. (I think that Owned shouldn't be doing this this way, but as yet I don't have a good alternative to propose that DC implement.) The problem is that once this is done, the LoginManager is no longer "unowned". To fix this, add the line:
_owner = UnownableOwner
to the body of the LoginManager class. This will ensure that even after _deleteOwnershipAfterAdd(), the LoginManager will remain "unowned".
Your logic is sound, and I'm glad you spotted the recursion problem, but I would like to propose a different solution.
After you have made this fix and restarted Zope, you may want to "un-own" any objects contained within your LoginManagers which might have been created with ownership. To do this, you should go to each page of each LoginManager's management interface and copy all objects, then paste them. Delete the originals, and rename the copies back to their old names. The copies will then be "unowned". You can verify this by checking each object's management interface: if it is unowned, it will have no "Ownership" tab.
Why does LoginManager want its contents unowned? It has to do with the new security model. When an executable object is owned, the security machinery wants to validate that its owner is allowed to do whatever the executable is doing. This is great except for the fact that in many sites, the owner of the LoginManager's objects is actually a user that was retrieved from that LoginManager. This means that if LoginManager executes an object to find out information about a user, and that object is owned by a user from that LoginManager, infinite recursion and a core dump will swiftly follow. For this reason, you should make sure that all executable objects in a LoginManager are either unowned or owned by a user who is *not* supplied by that LoginManager. In practice, making sure they're unowned is usually easier.
The new security machinery actually provides a different way to solve this problem. Since we now have an execution stack, we can limit that stack, causing an exception to be thrown rather than letting it overflow the C stack. It would actually be more reliable than the current mechanism, which depends on DTML namespaces. Now let's do an analysis of this situation. If the LoginManager is created by the superuser and is used as the root authenticator, it stays unowned, so the ownership problem should not occur. If that is not the current behavior then it needs to be corrected. If untrusted users are allowed to add LoginManagers, the methods called to get ownership information should be owned by them. This is to avoid the server-side trojan horse. I used to think that the new security model was a break from the *nix security model. But consider this: sysadmins don't go around executing arbitrary users' scripts, do they? Of course not. The only parallel to what Zope provides is CGI scripts. Sysadmins are able to visit arbitrary CGI scripts without worry of a server-destined trojan (although a client-destined trojan is another matter) because the scripts are not given extra privileges. In fact, the suexec add-on makes Apache behave almost exactly the way Jim is getting Zope to behave. Now, the problem still remains that ownership information cannot be retrieved if the method that gets ownership is in ZODB, is owned by a user defined in that user folder, and has to call another method. Note that this also applies to Generic User Folder. With the correction in the execution stack, instead of killing Zope, an attempt to authenticate that way will result in a controlled stack overflow. Unless you can come up with another option, we can either break the security model or slightly reduce the capabilities of LoginManager. What would you do if you were in my position? Shane
At 09:22 AM 7/10/00 -0400, Shane Hathaway wrote:
The new security machinery actually provides a different way to solve this problem. Since we now have an execution stack, we can limit that stack, causing an exception to be thrown rather than letting it overflow the C stack. It would actually be more reliable than the current mechanism, which depends on DTML namespaces.
That would probably be a good idea, independent of LoginManager et al.
If the LoginManager is created by the superuser and is used as the root authenticator, it stays unowned, so the ownership problem should not occur. If that is not the current behavior then it needs to be corrected.
That is not the current behavior, unless _owned=UnownableOwner is placed in the class.
If untrusted users are allowed to add LoginManagers, the methods called to get ownership information should be owned by them. This is to avoid the server-side trojan horse.
Understood. I'll try to keep that use case in mind. Keep in mind, however, that being able to create a LoginManager is a pretty risky business in a portalish environment - you could potentially get access to somebody's password, since after all you will control an actual login screen! (Note however, that someone can create a phony login screen in DTML and bypass the entire Zope security model with a little "social engineering" anyway.) Also note that it is not necessary to give a user access to the full power of LoginManager. One could give them rights only to add a small subset of the available UserSources and LoginMethods. It would probably be a bad idea to give them the ability to add a GenericUserSource, which is where most of the potential for mayhem lies. Better to give them some sort of PersistentUserSource, with no ability to do much.
Now, the problem still remains that ownership information cannot be retrieved if the method that gets ownership is in ZODB, is owned by a user defined in that user folder, and has to call another method. Note that this also applies to Generic User Folder.
Yep. The problem is that the superuser *can't* create those methods in the root folder, so there's no place to bottom out the recursion at present.
With the correction in the execution stack, instead of killing Zope, an attempt to authenticate that way will result in a controlled stack overflow. Unless you can come up with another option, we can either break the security model or slightly reduce the capabilities of LoginManager.
What would you do if you were in my position?
Well, I'm hoping you'll take a look at my Collector suggestion for a new Zope feature. :) Specifically, extending the "access" file to allow other "top-level" users to exist besides the superuser, who have roles defined in the file. There are many ways this would be useful, not the least of which is to break the "you need to do that at the next level up" problem. (Others include a simplified process for getting your Zope site set up, since you then don't have to login as superuser and add a user folder, then log back in as somebody else.) If this were done, we could easily go to letting LoginManager objects be owned, since there'd always be a place "above" the LoginManager for the owner user to reside.
"Phillip J. Eby" wrote:
At 09:22 AM 7/10/00 -0400, Shane Hathaway wrote:
The new security machinery actually provides a different way to solve this problem. Since we now have an execution stack, we can limit that stack, causing an exception to be thrown rather than letting it overflow the C stack. It would actually be more reliable than the current mechanism, which depends on DTML namespaces.
That would probably be a good idea, independent of LoginManager et al.
Well, guess what... Jim's ahead of both of us. Not only is the stack size limited, but the limit is easily configured through an environment variable. I never give this guy enough credit. :-) See lib/python/AccessControl/SecurityManager.py, especially addContext().
If the LoginManager is created by the superuser and is used as the root authenticator, it stays unowned, so the ownership problem should not occur. If that is not the current behavior then it needs to be corrected.
That is not the current behavior, unless _owned=UnownableOwner is placed in the class.
It looks like Brian decided, for the latest beta, to make ownership forgiving in the presence of an _owner class attribute. This should solve the problem for Generic User Source. Generic User Folder is going to need the _owner attribute.
If untrusted users are allowed to add LoginManagers, the methods called to get ownership information should be owned by them. This is to avoid the server-side trojan horse.
Understood. I'll try to keep that use case in mind. Keep in mind, however, that being able to create a LoginManager is a pretty risky business in a portalish environment - you could potentially get access to somebody's password, since after all you will control an actual login screen! (Note however, that someone can create a phony login screen in DTML and bypass the entire Zope security model with a little "social engineering" anyway.)
I've thought of that as well. Perhaps we'll have to accept that the new model just doesn't lend itself to the area of configurable user databases.
Also note that it is not necessary to give a user access to the full power of LoginManager. One could give them rights only to add a small subset of the available UserSources and LoginMethods. It would probably be a bad idea to give them the ability to add a GenericUserSource, which is where most of the potential for mayhem lies. Better to give them some sort of PersistentUserSource, with no ability to do much.
Now, the problem still remains that ownership information cannot be retrieved if the method that gets ownership is in ZODB, is owned by a user defined in that user folder, and has to call another method. Note that this also applies to Generic User Folder.
Yep. The problem is that the superuser *can't* create those methods in the root folder, so there's no place to bottom out the recursion at present.
With the correction in the execution stack, instead of killing Zope, an attempt to authenticate that way will result in a controlled stack overflow. Unless you can come up with another option, we can either break the security model or slightly reduce the capabilities of LoginManager.
What would you do if you were in my position?
Well, I'm hoping you'll take a look at my Collector suggestion for a new Zope feature. :) Specifically, extending the "access" file to allow other "top-level" users to exist besides the superuser, who have roles defined in the file. There are many ways this would be useful, not the least of which is to break the "you need to do that at the next level up" problem. (Others include a simplified process for getting your Zope site set up, since you then don't have to login as superuser and add a user folder, then log back in as somebody else.)
If this were done, we could easily go to letting LoginManager objects be owned, since there'd always be a place "above" the LoginManager for the owner user to reside.
Hmm... this sounds like a good idea, but now that the ownership problem has been resolved in a way I didn't expect, the issue that motivated your idea is gone. Shane
At 03:07 PM 7/10/00 -0400, Shane Hathaway wrote:
"Phillip J. Eby" wrote:
Understood. I'll try to keep that use case in mind. Keep in mind, however, that being able to create a LoginManager is a pretty risky business in a portalish environment - you could potentially get access to somebody's password, since after all you will control an actual login screen! (Note however, that someone can create a phony login screen in DTML and bypass the entire Zope security model with a little "social engineering" anyway.)
I've thought of that as well. Perhaps we'll have to accept that the new model just doesn't lend itself to the area of configurable user databases.
I'm not sure which model you mean, here, but in any case I think the new security model is fine, *except* for the absence of a "root" user folder that is outside of Zope and is always present when you install Zope.
Well, I'm hoping you'll take a look at my Collector suggestion for a new Zope feature. :) Specifically, extending the "access" file to allow other "top-level" users to exist besides the superuser, who have roles defined in the file. There are many ways this would be useful, not the least of which is to break the "you need to do that at the next level up" problem. (Others include a simplified process for getting your Zope site set up, since you then don't have to login as superuser and add a user folder, then log back in as somebody else.)
If this were done, we could easily go to letting LoginManager objects be owned, since there'd always be a place "above" the LoginManager for the owner user to reside.
Hmm... this sounds like a good idea, but now that the ownership problem has been resolved in a way I didn't expect, the issue that motivated your idea is gone.
Maybe, maybe not. I think perhaps the most compelling argument from Digital Creations' viewpoint for having an expanded "access" file might be the simplification of the setup process for customers. And it would also make it easier to: 1) Phase out unownedness (user databases wouldn't need it) 2) Narrow the role of superuser (super-can-create hack can go away) 3) Do Zope virtual hosting and give somebody a Zope root and even superuser, while still being able to log in 4) Stop all the whining from people who want to know why superuser can't create or own objects any more. :)
Jim, Phillip has an idea that could make life simpler for Zope newbies. This would be intended for the next major Zope release. "Phillip J. Eby" wrote:
Well, I'm hoping you'll take a look at my Collector suggestion for a new Zope feature. :) Specifically, extending the "access" file to allow other "top-level" users to exist besides the superuser, who have roles defined in the file. There are many ways this would be useful, not the least of which is to break the "you need to do that at the next level up" problem. (Others include a simplified process for getting your Zope site set up, since you then don't have to login as superuser and add a user folder, then log back in as somebody else.)
If this were done, we could easily go to letting LoginManager objects be owned, since there'd always be a place "above" the LoginManager for the owner user to reside.
Hmm... this sounds like a good idea, but now that the ownership problem has been resolved in a way I didn't expect, the issue that motivated your idea is gone.
Maybe, maybe not. I think perhaps the most compelling argument from Digital Creations' viewpoint for having an expanded "access" file might be the simplification of the setup process for customers. And it would also make it easier to:
1) Phase out unownedness (user databases wouldn't need it) 2) Narrow the role of superuser (super-can-create hack can go away) 3) Do Zope virtual hosting and give somebody a Zope root and even superuser, while still being able to log in 4) Stop all the whining from people who want to know why superuser can't create or own objects any more. :)
As I understand it, the reason we needed to revoke capabilities from the superuser was to ensure there was someone who could be assigned ownership for every object. Do you think an expanded access file, which would include multiple users and role lists, would enable us to reduce the magnitude of the SuperCannotOwn dilemma? Perhaps during installation the user would set up two user accounts, a superuser and a normal user. Shane
FYI, I entered a Collector feature request for this over the weekend; I classified it as "somewhat important/future", IIRC. It mentions the "set up two accounts" concept you describe below, and I think there might be some other notes as well. At 05:07 PM 7/10/00 -0400, Shane Hathaway wrote:
Jim,
Phillip has an idea that could make life simpler for Zope newbies. This would be intended for the next major Zope release.
As I understand it, the reason we needed to revoke capabilities from the superuser was to ensure there was someone who could be assigned ownership for every object. Do you think an expanded access file, which would include multiple users and role lists, would enable us to reduce the magnitude of the SuperCannotOwn dilemma? Perhaps during installation the user would set up two user accounts, a superuser and a normal user.
"Phillip J. Eby" wrote:
Maybe, maybe not. I think perhaps the most compelling argument from Digital Creations' viewpoint for having an expanded "access" file might be the simplification of the setup process for customers. And it would also make it easier to:
1) Phase out unownedness (user databases wouldn't need it) 2) Narrow the role of superuser (super-can-create hack can go away) 3) Do Zope virtual hosting and give somebody a Zope root and even superuser, while still being able to log in 4) Stop all the whining from people who want to know why superuser can't create or own objects any more. :)
This sounds great, what happened about it? cheers, Chris
Chris Withers wrote:
"Phillip J. Eby" wrote:
Maybe, maybe not. I think perhaps the most compelling argument from Digital Creations' viewpoint for having an expanded "access" file might be the simplification of the setup process for customers. And it would also make it easier to:
1) Phase out unownedness (user databases wouldn't need it) 2) Narrow the role of superuser (super-can-create hack can go away) 3) Do Zope virtual hosting and give somebody a Zope root and even superuser, while still being able to log in 4) Stop all the whining from people who want to know why superuser can't create or own objects any more. :)
This sounds great, what happened about it?
You speak in the past tense. This is only a suggestion and a possibility. It's not as important as some other feature requests. Shane
At 10:15 AM 7/19/00 -0400, Shane Hathaway wrote:
Chris Withers wrote:
"Phillip J. Eby" wrote:
Maybe, maybe not. I think perhaps the most compelling argument from Digital Creations' viewpoint for having an expanded "access" file
might be
the simplification of the setup process for customers. And it would also make it easier to:
1) Phase out unownedness (user databases wouldn't need it) 2) Narrow the role of superuser (super-can-create hack can go away) 3) Do Zope virtual hosting and give somebody a Zope root and even superuser, while still being able to log in 4) Stop all the whining from people who want to know why superuser can't create or own objects any more. :)
This sounds great, what happened about it?
You speak in the past tense. This is only a suggestion and a possibility. It's not as important as some other feature requests.
Patch opportunity, perhaps? :) Ty and I would do it, no problem. Heck, I've been tempted to do it as a LoginManager function, since Zope doesn't pay attention to anything past the first line of the "access" file...
"Phillip J. Eby" wrote:
At 10:15 AM 7/19/00 -0400, Shane Hathaway wrote:
Chris Withers wrote:
"Phillip J. Eby" wrote:
Maybe, maybe not. I think perhaps the most compelling argument from Digital Creations' viewpoint for having an expanded "access" file
might be
the simplification of the setup process for customers. And it would also make it easier to:
1) Phase out unownedness (user databases wouldn't need it) 2) Narrow the role of superuser (super-can-create hack can go away) 3) Do Zope virtual hosting and give somebody a Zope root and even superuser, while still being able to log in 4) Stop all the whining from people who want to know why superuser can't create or own objects any more. :)
This sounds great, what happened about it?
You speak in the past tense. This is only a suggestion and a possibility. It's not as important as some other feature requests.
Patch opportunity, perhaps? :) Ty and I would do it, no problem. Heck, I've been tempted to do it as a LoginManager function, since Zope doesn't pay attention to anything past the first line of the "access" file...
We would be most grateful! :-) Shane
At 11:09 AM 7/19/00 -0400, Shane Hathaway wrote:
Patch opportunity, perhaps? :) Ty and I would do it, no problem. Heck, I've been tempted to do it as a LoginManager function, since Zope doesn't pay attention to anything past the first line of the "access" file...
We would be most grateful! :-)
So are y'all at DC in agreement that this would be a useful feature with no pitfalls? Should we go through the new fishbowl process thing to do this?
"Phillip J. Eby" wrote:
At 11:09 AM 7/19/00 -0400, Shane Hathaway wrote:
Patch opportunity, perhaps? :) Ty and I would do it, no problem. Heck, I've been tempted to do it as a LoginManager function, since Zope doesn't pay attention to anything past the first line of the "access" file...
We would be most grateful! :-)
So are y'all at DC in agreement that this would be a useful feature with no pitfalls? Should we go through the new fishbowl process thing to do this?
Some of the crew are at oscon this week so they'll have to answer when they get back. But I am of the opinion that the fishbowl process is only needed for relatively major changes. Small modifications can just be posted, reviewed, and merged. Shane
At 12:50 PM 7/19/00 -0400, Shane Hathaway wrote:
"Phillip J. Eby" wrote:
At 11:09 AM 7/19/00 -0400, Shane Hathaway wrote:
Patch opportunity, perhaps? :) Ty and I would do it, no problem.
Heck,
I've been tempted to do it as a LoginManager function, since Zope doesn't pay attention to anything past the first line of the "access" file...
We would be most grateful! :-)
So are y'all at DC in agreement that this would be a useful feature with no pitfalls? Should we go through the new fishbowl process thing to do this?
Some of the crew are at oscon this week so they'll have to answer when they get back. But I am of the opinion that the fishbowl process is only needed for relatively major changes. Small modifications can just be posted, reviewed, and merged.
Hm. I don't think this could be classed as a "minor" change, however, since it has impact on ownership, for example. What's the path of the user folder which is above "/", for example? The whole thing is useless if these extra users can't be owners, and the ownership machinery right now wants an access path. I think perhaps we should go the fishbowl route on this, if only to make sure that Jim doesn't have a heart attack when he gets back. :)
At 01:27 PM 7/19/00 -0500, Phillip J. Eby wrote:
Hm. I don't think this could be classed as a "minor" change, however, since it has impact on ownership, for example. What's the path of the user folder which is above "/", for example? The whole thing is useless if these extra users can't be owners, and the ownership machinery right now wants an access path. I think perhaps we should go the fishbowl route on this, if only to make sure that Jim doesn't have a heart attack when he gets back. :)
Looks like I was wrong. This was in fact quite a minor patch. I've only tested this lightly so far, but if anyone else wants to try it out, here it is. Note that the new "access" file format looks like this: # Lines beginning with '#' are comments # # First user in file is "super" user, unless roles # are specified, in which case there is NO superuser # superusername:{SHA}fsjdflfs:domain1.com # # Format for all other users is name:pw:domains:roles # somemanager:{SHA}rr70flksf::Manager Editor SomeotherRole somedeveloper:{CRYPT}flsdajfd:domain2.com:Manager You can access a dictionary of all the "access" file users by importing rootUsers from AccessControl.SpecialUsers. It is a dictionary mapping user names to user objects. Be sure to use __of__ to wrap them to your UserFolder if you are adding support for this to a UserFolder variant. I have not yet added support for this to LoginManager, but as you'll see from the changes to the basic UserFolder, it is probably not going to be at all difficult to do so. Patch follows; watch out for line wrapping... Index: User.py =================================================================== RCS file: /cvs-repository/Zope2/lib/python/AccessControl/User.py,v retrieving revision 1.112 diff -u -r1.112 User.py --- User.py 2000/07/11 18:42:48 1.112 +++ User.py 2000/07/23 01:38:51 @@ -314,13 +314,30 @@ 'No access file found at %s - see INSTALL.txt' % INSTANCE_HOME ) try: - data=split(strip(f.readline()),':') - f.close() - _remote_user_mode=not data[1] - try: ds=split(data[2], ' ') - except: ds=[] - super=Super(data[0],data[1],('manage',), ds) - del data + d=f.readlines(); f.close(); del f + rootUsers = SpecialUsers.rootUsers = {} + + for data in map(strip,d): + if not data or data[0]=='#': continue + data=split(data+':::',':') # allow for missing fields + + n = data[0] + ds = split(strip(data[2])) # space-delimited domains + pw = data[1] + r = split(strip(data[3])) # space-delimited roles + + if rootUsers or r: + # If not first user in file, or if roles are specified, + # user is a "normal" user object + rootUsers[n] = SimpleUser(n,data[1],tuple(split(data[3])),data[2]) + else: + super = rootUsers[n] = Super(n,pw,('manage',), ds) + _remote_user_mode=not pw + + del data,n,ds,pw,r + + del d + except: raise 'InstallError', 'Invalid format for access file - see INSTALL.txt' @@ -383,6 +400,11 @@ """ try: return self.getUser(id) except: + + # Don't return the superuser, so that super can't own things + if rootUsers.has_key(id) and id!=super.getUserName(): + return rootUsers[id].__of__(self) + if default is _marker: raise return default @@ -405,7 +427,6 @@ _remote_user_mode=_remote_user_mode - _super=super _nobody=nobody def validate(self,request,auth='',roles=None): @@ -440,11 +461,11 @@ return None name,password=tuple(split(decodestring(split(auth)[-1]), ':', 1)) - # Check for superuser - super=self._super - if self._isTop() and (name==super.getUserName()) and \ - super.authenticate(password, request): - return super + # Check for superuser/root users + if self._isTop() and rootUsers.has_key(name): + user = rootUsers[name].__of__(self) + if user.authenticate(password, request): + return user # Try to get user user=self.getUser(name) @@ -508,10 +529,9 @@ return ob return None - # Check for superuser - super=self._super - if self._isTop() and (name==super.getUserName()): - return super + # Check for superuser/root users + if self._isTop() and rootUsers.has_key(name): + return rootUsers[name].__of__(self) # Try to get user user=self.getUser(name) @@ -560,7 +580,7 @@ title ='Illegal value', message='Password and confirmation must be specified', action ='manage_main') - if self.getUser(name) or (name==self._super.getUserName()): + if self.getUser(name) or (rootUsers.has_key(name)): return MessageDialog( title ='Illegal value', message='A user with the specified name already exists',
I've further enhanced yesterday's patch with the following additions: * "Short-circuit evaluation" of local roles in User.getRolesInContext(). This speeds up security evaluation for complex DTML by stopping the local role search as soon as one of the desired roles is found. The change is fully backward compatible with any other usage of getRolesInContext() (although there *arent'* any other usages in the Zope core). (Note: this change also prevents infinite recursion of local roles lookup when the local roles are provided by a ZPatterns attribute provider which is owned by a user who has the necessary roles to compute local roles.) * Encapsulation fix. The current version of Zope directly accesses __ac_local_roles__ when checking access rights, which negates any ability for Zope objects to provide rule-based local roles without computing all possible roles for all possible users. * Added "get_local_roles_for_user()" method to AccessControl.Role.RoleManager that works with a user object, rather than a user name. This is to allow objects to supply computed local roles using attributes of the user as part of their decision process. An object need only implement get_local_roles_for_user(user,roles) to carry this out. These additions, in conjunction with the ability to add more users to the "access" file, will allow ZPatterns and LoginManager to do without 'unownedness' and other convoluted alterations of the Zope security model. They will also make it possible to add local role plugins to ZPatterns. This is somewhat more tested than yesterday's variant of the patch, although I have not found any bugs in what I posted yesterday. The post itself was flawed, however; this time I'm attaching it as a file in the hopes of preventing that happening again. If there are no comments/questions/feedback on it, I'd like to go ahead and submit it to the Collector for inclusion in Zope CVS; as it will make continued development of ZPatterns and LoginManager much cleaner and in full compliance with the 2.2 security model. As I move further into the development of local role plugin support for ZPatterns, I may have additional patches to suggest, as there are some other encapsulation/interface issues with the "get_local_roles()" method as currently used/implemented in Zope. Most likely, there needs to be a "get_users_with_local_role()" method for those uses, leaving "get_local_roles()" to mean "get *editable* local roles". Also, ObjectManager still inspects __ac_local_roles__ rather than going through an interface to set the initial owner role of an object. Personally, I think this should be done by one of the many other after-add type calls such as manage_afterAdd or manage_fixupOwnershipAfterAdd, etc., but backward compatibility for that would be tricky. Patch follows.
On Sat, 22 Jul 2000 20:48:28 -0500, "Phillip J. Eby" <pje@telecommunity.com> wrote:
At 01:27 PM 7/19/00 -0500, Phillip J. Eby wrote:
Hm. I don't think this could be classed as a "minor" change, however, since it has impact on ownership, for example. What's the path of the user folder which is above "/", for example? The whole thing is useless if these extra users can't be owners, and the ownership machinery right now wants an access path. I think perhaps we should go the fishbowl route on this, if only to make sure that Jim doesn't have a heart attack when he gets back. :)
Looks like I was wrong. This was in fact quite a minor patch. I've only tested this lightly so far, but if anyone else wants to try it out, here it is. Note that the new "access" file format looks like this:
Woohoo. I figure this is a big advantage for my newbie zope managers. Toby Dickenson tdickenson@geminidataloggers.com
"Phillip J. Eby" wrote:
You speak in the past tense. This is only a suggestion and a possibility. It's not as important as some other feature requests.
Patch opportunity, perhaps? :) Ty and I would do it, no problem. Heck, I've been tempted to do it as a LoginManager function, since Zope doesn't pay attention to anything past the first line of the "access" file...
I think it'd help newbies a lot... A patch would be great if you can manage it :-) cheers, Chris
participants (4)
-
Chris Withers -
Phillip J. Eby -
Shane Hathaway -
Toby Dickenson