RE: [Zope-dev] PATCH: Expanded access file
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. Hi all - I think that this is _definitely_ the kind of thing that should be done in the fishbowl on dev.zope.org. Why? Because while it may be a "minor patch" in terms of lines of code, just applying the patch causes a number of problems that have nothing to do with software per se. They are the same problems that I get beaten about on a daily basis for everything that has ever been added to Zope to date :^) They are the problems that dev.zope.org is being designed to solve: o There is no visibility of the reason for the change. What is the problem being solved? How exactly does this solve it? Is it the right solution? Why did we make the decisions we made? Of course some discussion of these has occurred on the dev list, but the only way I (or anyone else) can discover these is to piece things together by searching list archives. o There is no visibility of the impacts of the change. How does this affect ownership? Does this work with all existing user folder objects, or do they all need to change to support it? If they all need to change, shouldn't we make sure that the authors of other implementation generally buy into this? What other issues might there be? Again, we can only scour the list archives :( o This would become Yet Another Undocumented Feature. One of the big things that the dev area is going to do is to force us to assess the documentation impact of changes and ensure that the required documentation is produced and integrated with the appropriate offical or unofficial docs. I can see the expanded access file change potentially having an effect on at least two kinds of documentation (user/admin guides and developer materials regarding how to implement new kinds of user folders). The structure of projects in the dev area is such that a finished project tells a story. What was the problem? What was the solution? How was it done? What documentation or other resources were created as a result? All of those things are available in one place once a project is complete. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] PATCH: Expanded access file
At 10:54 AM 7/25/00 -0400, Brian Lloyd wrote: I think that this is _definitely_ the kind of thing that should be done in the fishbowl on dev.zope.org. Why? Because while it may be a "minor patch" in terms of lines of code, just applying the patch causes a number of problems that have nothing to do with software per se. Sorry about that. As you may have seen from the list, I did enquire as to whether this should go in the fishbowl, and was told that such a minor patch probably didn't need it. I thought the issue was more complex than it was also; I was under the impression that Zope had a user folder *above* the official "root", not realizing that it was merely that the "physical root" had a default user folder in existence. What is the problem being solved? How exactly does this solve it? Is it the right solution? Why did we make the decisions we made? Of course some discussion of these has occurred on the dev list, but the only way I (or anyone else) can discover these is to piece things together by searching list archives. Problem being solved: the new ownership model requires a place for ownership to "bottom out" so that user databases themselves can have owners. The previous solution was the creatable-by-super hack, which only created further holes in the ownership model, since user databases which involved components which followed the security model (e.g. GenericUserFolder and LoginManager) then had to suppress ownership characteristics or else be unusable as a root-level user database. Second problem: the initial existence of only a single Zope user who could not actually do anything except create a UserFolder, was troubling to new users of Zope and at best inconvenient for experienced ones. o There is no visibility of the impacts of the change. How does this affect ownership? Does this work with all existing user folder objects, or do they all need to change to support it? * The "rootUsers" can own things * They appear to be normal members of the root UserFolder, except that they do not appear in its contents as they are not stored there. * It is not necessary for a user database to support the rootUsers; however if the top-level user database of a Zope installation does not support them, they will not be usable in that installation. * User databases using the existing name==super.getUserName() protocol are unaffected; they simply will not provide access to the new rootUser objects. * User folder objects must be changed to support the rootUsers dictionary. The patch provides this support for the Zope UserFolder object. In practice, I believe that there is a relatively small (i.e. near-zero) number of publically-available user databases currently in existence which correctly support the Zope 2.2 security model, apart from those developed by DC themselves. Private developers of user databases need only implement the support if they would like the additional feature, and for the rest, I believe this patch should actually make it easier to implement 2.2 support for most such user databases, since they won't need to implement the creatable-by-super protocol or work through ownership issues. o This would become Yet Another Undocumented Feature. One of the big things that the dev area is going to do is to force us to assess the documentation impact of changes and ensure that the required documentation is produced and integrated with the appropriate offical or unofficial docs. I can see the expanded access file change potentially having an effect on at least two kinds of documentation (user/admin guides and developer materials regarding how to implement new kinds of user folders). My assumption was that this feature would actually be easier for DC to document than explaining to someone why they have to log in as superuser, create a user folder, put a user in it, then log out by closing their browser, and then log back in again as that other user in order to start using their Zope installation. My intent was to make both your and my life easier, not more complex. I apologize for any such side effect. :( ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] PATCH: Expanded access file
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
