IRC log of #zope3-dev for Sunday, 2005-06-05

« Saturday, 2005-06-04 Index Monday, 2005-06-06 »
*** elbixio has joined #zope3-dev00:00
*** elbixio has quit IRC00:08
*** hazmat_ has quit IRC01:20
*** jhauser has quit IRC01:25
*** d2m has quit IRC02:04
*** yota has quit IRC02:04
*** hazmat_ has joined #zope3-dev02:38
*** povbot` has joined #zope3-dev02:45
*** povbot has quit IRC02:45
*** hazmat_ has quit IRC03:11
*** hazmat has joined #zope3-dev03:15
*** hazmat has quit IRC03:57
*** hazmat has joined #zope3-dev04:45
*** projekt01 has quit IRC04:57
*** guido_g has quit IRC06:16
*** tarek has quit IRC06:47
*** hazmat has quit IRC07:32
*** hazmat has joined #zope3-dev07:35
*** hazmat has joined #zope3-dev08:34
*** hazmat has quit IRC08:47
*** yutakashino has joined #zope3-dev11:13
*** yutakashino has quit IRC11:31
*** yutakashino_ has joined #zope3-dev11:31
*** yutakashino_ is now known as yutakashino11:31
*** yota has joined #zope3-dev11:44
*** tarek has joined #zope3-dev13:02
*** The|uni has joined #zope3-dev13:12
*** J1m has joined #zope3-dev13:38
*** projekt01 has joined #zope3-dev14:04
The|uniSteveA:  hi. i'm starting to do the certification stuff now. i'll need some minutes to get into it. i'll talk to you when i need help. ok?14:15
*** d2m has joined #zope3-dev14:24
The|uniSubversionException: ('Berkeley DB error while checkpointing after Berkeley DB transaction for filesystem /svn/repos/main/db:\nDB_INCOMPLETE: Cache flush was unable to complete', 160029)14:38
The|uniCan someone revive the zope 3 svn?14:38
VladDracand move to the fsfs backend :)14:39
srichterJ1m can do this14:39
srichterfsfs backend: once we switch to SVN 1.2 we can14:39
J1msrichter, don't volunteer me for things14:39
mexiKONi think 1.1 has the fsfs backend14:40
The|uni1.1 has14:40
srichterJ1m: I just volunteered you to restore the DB14:40
The|unii'm on 1.1 and we are using the fsfs backend for gocept since a month14:40
srichternothing else ;-)14:40
J1mdone14:41
J1mswitching to a fs backend is non-trivial14:42
J1mThe|uni, did you switch from bdb to fs?14:42
mexiKONwell, you have to dumb and restore the whole db14:42
J1mor did you start with fs14:42
J1mmexiKON, That's what I assumed.14:43
The|uniJ1m:  i was so fortunate to start with it :)14:44
The|unibut all that dumping stuff seems fairly easy14:44
VladDracj1m: we did it this weekend - it's not that hard actually14:45
The|uniI made a mid-sized CVS to SVN migration which actually uses the dumps as an intermediate format.14:45
J1mIt's probably not that hard, but:14:45
J1mIt requires I spend time figuring out how to do it14:45
J1mIt will take a lot of time for the zope repo, which is fairly large14:45
The|unijupp14:46
mexiKONit'll only grow larger the longer we wait :)14:46
J1mI have to make sure the entire config works, including backup, viewcvs, etc.14:46
J1mThe point is that it will take a significant chuck of time.14:46
J1mThe point is that it will take a significant chunk of time.14:46
VladDracto get you started (for future reference): svn dump; svn create -fsfs (I think), svn load14:46
VladDractrue14:46
J1mNot something I have handy. :)14:47
mexiKONyup14:47
VladDracwell most of it is waiting14:47
The|uninp. I didn't suggest anyone to rush anything right now.14:47
VladDracbut true, it takes time and some thorough planning14:47
VladDrac(neither do I,  but if I can be of any help when you do migratie, let me know)14:47
The|uniHmm. Looks like some people are around that could answer some questions for the certification.14:48
The|uniI'm on revising the specification document to match the current state of zope 3 a bit more closely, but I'm way out of the loop since a while.14:48
The|unia) we mention a "delegation" concept in the specs that regulate permission grants.14:49
The|uniWe described it like this:14:50
The|uni  Provide the ability to securely delegate control. Users can14:50
The|uni  delegate the ability to control access to selected14:50
The|uni  operations to others. To delegate a permission, a meta permission14:50
The|uni  that allows you to delegate this permission must be granted.14:50
The|uniIs this around already or will be around, or possible to be around, or around in some other way?14:50
The|uniI'm digging through code right now, but this is pretty slow as everything seems changed to me. :)14:50
J1mno, we never implemented this14:51
The|uniso how does it actually work now?14:51
The|uniis there a single permission that protects all granting?14:51
J1mI seem to remember discussing a security policy that we never implemented.14:52
J1mYes14:52
The|uniOk. Do you imagine it's better to remove this from the specs or still aim for it?14:52
J1mThe current security policy is documented in:14:53
The|uniThe certification project suffers from substantial lack of resources, so I'm trying to stay as close to the actual current state as possible.14:53
J1mhttp://svn.zope.org/Zope3/trunk/src/zope/app/securitypolicy/zopepolicy.txt?rev=29768&view=log14:53
J1msorry14:53
J1mhttp://svn.zope.org/Zope3/trunk/src/zope/app/securitypolicy/zopepolicy.txt?rev=29768&view=markup14:54
J1mI still think that the sharing policy I sent you is:14:55
J1m- Easier to document14:55
J1m- Easier for users to understand14:55
The|uniWhich still is a problem. I think I'm currently only doing cleanup work.14:55
The|uniThe document was intended to have been submitted last week.14:56
The|uniAnd I have no time in the next 8 weeks for spending on the certification again.14:56
J1mI'm sorry I haven't had time to review it14:56
The|uniSteve looked through it and gave me a list of points.14:56
J1mGreat!14:56
The|uniI don't see a chance to change to a completely different policy in the timeframe, though.14:57
The|uniSo I'm going through those points now and try cleaning them up today.14:57
The|uniHere comes a question: The policy documentation says "Managers can grant or deny..."14:57
mexiKONThe|uni, btw, when i read thru the document a while ago, i saw you mixed up the meaning of 'trunk' and 'HEAD' a few times14:57
mexiKONThe|uni, HEAD is a revision in svn, 'trunk' is a branch14:58
The|unimexiKON:  i'll write that down. that came from the fact that we originally were still on CVS when that text was written.14:58
mexiKONyup14:58
The|uniSo who is a "Manager"?14:58
mexiKONbasically, one should only talk about the trunk14:58
The|unimexiKON:  ack14:58
*** bskahan has joined #zope3-dev14:59
The|uniHmm. Hmm.15:03
The|uniSo the manager role simply get's all defined permissions.15:03
The|uniwhich obviously would include any permission for granting/denying stuff15:04
The|uniah. the zope.Security permission seems to be the relevant one.15:04
srichteryes15:04
The|uninow comes the fun part.15:05
srichtera Manager is a principal with the zope.Manager role15:05
J1mThis is purely a configuration choice15:05
The|unichanging a part of the specs in the beginning and tracing down any implications15:05
J1mZope need not be configured this way.15:05
srichterbote that the persmission assignment of the zope.Manager role is more subtle15:05
srichternote that the persmission assignment of the zope.Manager role is more subtle15:05
The|uniJ1m:  sure, but I need to be a bit specific ...15:06
srichterby default, the Manager gets the permissions that are defined by the time the manager role is created15:06
J1mJust so you aren't specific and wrong15:06
srichterso if you create a permission later, then the manager will not have it15:06
srichter(this bit me badly once)15:07
The|unisrichter:  hmm. i thought this to be a problem already, then i thought "maybe they fixed that, maybe it's been accepted to be that way"15:07
The|uniJ1m: I'm trying. :)15:08
srichterThe|uni: it is pretty much accepted15:09
srichteror just not well known :-)15:09
The|uniso is it that this declaration is usually run pretty much towards the end of configuration?15:10
srichteryes15:10
J1myes15:10
The|unik15:10
srichterthe principals.zcml is the last thing loaded15:10
srichteroh, never mind; the role is created before that15:10
The|uni:)15:10
The|uniJ1m:  I think I'll make it a limitation that the certified version can only be run with the default security policy. I don't see a reasonable way around this.15:13
The|uniI'm pretty sure many people can live with it.15:13
The|uniWhen people touch the security policy I can see a significant problem with the reliability of the certification to remain valid.15:14
J1mare you also going to depend on a default configuration of the sp?15:15
J1m(e.g. the notion of "managers")15:15
The|uniI'm not sure about that. Everything else becomes *so* blurry immediately.15:16
The|uniI mean, this flexibility forces me to write "Users can only do what they are allowed to do"15:16
The|uniI don't think anyone would certify that. :/15:16
J1mThat's why I recommend switching to a simpler security policy.15:17
J1mUnfortunately, it's getting to be too late to switch for 3.1.15:17
J1mBut even with the current security policy, it should be possible to document it accurately.15:18
J1mYou just have t build it up in layers.15:18
The|uniRight. But if I shouldn't document *any* part of configuration I wouldn't even be able to refere to zope.Security, right?15:19
J1mFor example: "An interaction can access a resource if it has the required permission."15:19
J1mThen you have to define the rules for determining the required permission.15:19
J1mYou should document what can be configured.15:20
J1mYou could even document the default configuration to show how all of the pieces fit together,15:20
The|uni.oO(This certification is so painful ...)15:21
J1mYes, security is like that.15:21
The|uniIt's more about resources (time, money, ...)15:22
J1mI understand.15:22
J1mHere's an offer:15:23
J1mIf we switch to the sharing-based sp, I'll volunteer to document it in the CS.15:24
J1mIt might take me several weeks to squeeze in time to do this however.15:24
The|uniNice offer, but unfeasable regarding the time constraints. The customer who pays the certification itself is pretty annoyed right now. That's why we spend time on completing the security target here at gocept. The document in itself is pretty consistent, but also at a high degree fictive.15:26
J1mOK15:26
The|uniSo the work was moved a bit from documenting to implemeting.15:26
The|uniWhich buys us some time.15:26
The|uniIt's a drawback/compromise of course.15:27
J1m"implementing"?15:27
The|uniWell. We cleaned the document up that included some fiction that we (you, steve, I) invented some time ago.15:27
The|uniSo the fictional part would have to be implemented later.15:28
The|uniInstead of spending the work now on describing what is already there.15:28
The|uniI'm just trying to minimize the fictional part a bit.15:29
J1mand what if it is never implemented?15:29
The|uniwell, mitcon tries to organize resources for the implementation.15:29
The|unii'm not sure how much they get up with (people, money, ...)15:29
The|uniI'm talking to them at EP what their plans are.15:29
The|uniAre you around there?15:29
J1mno15:29
The|unihow pity.15:30
The|uniOk. Here is an attempt to rephrase the objective to allow delegation:15:33
The|uni  Provide the ability to securely delegate control. Principals that are granted15:34
The|uni  the zope.Security permission shall be able to grant (or deny) permissions to15:34
The|uni  other principals.15:34
The|uni  By default the zope.Manager role is assigned all permissions thus including15:34
The|uni  zope.Security for all managers.15:34
The|unis/assigned/granted/ of course15:35
J1mIN the current sp, there are 3 kinds of grants15:38
The|uniI saw an "undefined" around.15:38
The|uniActually the pattern of a single delegation permission makes zope.Security a really powerful permission.15:41
J1myes15:41
J1mtoo powerful15:41
J1mIt would ne nice if you could only deletage permissions you had15:42
J1mbut, that's too hard to figure out with the current schema, imo15:42
The|uniyup15:42
J1mbut, that's too hard to figure out with the current scheme, imo15:42
The|uniimplications about handing off zope.Security to others would be pretty hard to predict15:43
J1mYou *really* have to trust them.15:43
The|uniSure. They could kill you. :)15:44
J1mThat's why we call it safe delegation15:44
The|unialthough it isn't?15:44
The|uni:)15:44
J1mIN the sharing model, it's much easier to say: "Only allow users to share privileges that they have."15:45
* The|uni burns happily in the realm of trading on political issues15:46
The|uniI'd be glad to jump into a simpler model. I'm just _really_ scared about the time frame. If it would be possible to document it within say ... 5 hours ... I would be on it immediately. It's not a problem that it isn't around in Zope 3.115:47
The|uniOk. A deal. I print the model you send me out again, read it and compare it to the certification.15:47
* The|uni burns a bit more.15:48
J1m:)15:48
The|uniIf you support in convincing me that _I_ can document fast enough, I'll change.15:48
J1mCool15:48
* The|uni hands out syntax errors on english sentences.15:49
The|uniI'll read it again, first.15:49
* The|uni gets some lunch.15:50
J1mdown15:54
J1moops15:54
J1mwrong window15:54
The|uniOk.16:15
The|uniRead it again.16:15
The|uniWhat I understand:16:16
The|uniroles got replaced by privileges16:16
The|uninot permissions get granted directly but only through privileges16:17
The|unithe grant/deny/undefined situation got easier (not sure about that)16:17
* J1m waits for The|uni to finish16:17
The|uniwe have to talk about groups (have to do that anyway)16:18
The|uniI'm unsure about the delegation.16:18
The|uni(finish)16:18
J1mpriviledge->permission mapping in zcml conly, users can't change that16:18
J1mgrants are not acquired unless an object isn't sharable16:19
J1m(not sharable objects acquire all grants)16:19
J1mThere are super users that have all permissions ... for bootstraping purposes.16:19
J1mAnd (fiction): cannot share privs you don't have. (This is easy to add.)16:20
J1mNote that the non-acquisition of grants greatly reduces the need for deny16:21
J1mMajor goal is simplicity16:21
J1malso, pluggable policies for default grants:16:21
J1m- Creator gets all privs16:21
J1m- Container privs copied to new items16:22
The|uni.oO(I foresee a hack on sharing: If I grant "sharing" to someone without any other permission who on his own grants sharing to someone with a lot of priviledges that one can share those permissions back to him then. Kinda weird bootstrapping.)16:22
J1mThese automatic grants are very useful since most users never want to think about security.16:22
The|uniright16:22
J1myup wrt hack on sharing16:23
J1mI think you've summarized the sp in very few words16:23
J1mwhich is a good thing about the sp16:24
The|uniright16:24
The|uninow to the hard part. i'll print out the current certification docs and check for needed changes.16:24
The|uniI'll take the secure delegation as a wanted part of the fiction, ok?16:24
J1myes, we plan to do that for our current project.16:25
J1mInterestingly, I think there are 2 twists on it:16:25
J1m- You can share a priv if you have it directly (not via group)16:26
J1m- You can share a priv if you have it even via group16:26
J1mNot sure if we want to allow the later16:26
The|unii think you need to16:26
The|uniotherwise administrator groups become useless16:26
J1mwhy?16:27
The|unihow would they give someone else any privileges if they only received them through a group?16:27
J1mIs that a function of the admin group?16:28
J1mNote that there are super users.16:28
The|uniAnd in regard to spelling, groups are just a convenience for not granting stuff to everyone individually. So why should the semantics be different? Adds to the complexity imho.16:28
J1mThese are not a group16:28
The|uniI think it is a function of the admin group.16:28
J1mk16:28
The|uniMy current image of those super users is the same as in Z2 which is a kind of Unix root equivalent.16:29
The|uni(Just with the restriction that instead of "you should not do normal stuff with it" you "can't do normal stuff with it")16:30
J1myes16:30
J1mBootstrapping only16:30
The|uniack. so then managers in z2 can do everything including handing out permissions.16:30
J1mIf someone establishes such a group. Yes.16:31
The|uniyou described one in the documentation, i thought it would be a pre-configured group.16:33
The|uni"There is a special administrative group, defined by the policy, that has all privileges [...]"16:33
J1mI did? Hm.  No, this should be application defined.16:33
The|uniit even has doctests16:34
J1mThat is what I was refering to as the super users.16:36
* The|uni reads again16:36
The|uniwell. so if you want to keep the rules consistent, and this really is a group, you still might want the second option.16:37
J1mThis group is handled specially,16:38
J1mI don't think we want people loging in as members of this group normally.16:39
J1mI would encourage people to create their own admin groups for "routine" admin tasks.16:39
The|uniOk. So although we agree to disagree, we want the second option anyway?16:39
J1mok16:40
*** andrew_m has quit IRC16:40
The|unigood16:40
The|unii'm afk for a while, checking for the stuff that need changes16:41
*** J1m is now known as J1m|away16:42
*** yutakashino has left #zope3-dev16:42
*** J1m|away is now known as J1m17:05
*** philiMAC has joined #zope3-dev17:45
J1msrichter, ayt?17:50
srichterJ1m: yep17:50
srichterI saw your +1, so we have to get Sidnei going :-)17:51
J1mso are we pushing the release till next week?17:51
srichteryeah17:51
J1mcool17:51
*** philiMAC is now known as philIKON17:51
J1mI'm working on it a bit this morning17:51
J1mBut I have to stop soon17:51
srichterok, cool17:51
srichterI was going to work on it in the evening17:52
J1mI wanna make some zpkg improvements to make the process a little easier. At least for me. :)17:52
srichtersuch as?17:52
J1mAllowing relative paths in maps.17:52
J1mThis will allow me to check in maps for the zope release that use local files.17:52
srichterI think refactoring the Python version specification from zpkgtools to one of the config files would be necessary17:52
srichterah17:53
J1mI've got it working17:53
*** mexiKON has quit IRC17:53
J1mBut I need to write a test17:53
J1mand I probably won't have time this morning17:53
J1mI'm also chasing errors in the geneates release17:54
J1mLater, I need to add some missing pieces.17:54
srichterok17:54
srichterthat's fine for now, since we do not release till next weekend17:54
J1mhow can we arrange that apidoc/introspector only run in debug mode?17:54
J1monly get used in debug mode?17:55
srichterby defining a feature17:55
srichterand check for the feature in the registration17:55
J1mThere is a serious security issue with them since they are (or one of them is) willing to import arbitrary modules.17:56
J1mCan you chase that?17:56
srichterI know the code that does it17:57
srichterbut I have no time right now to look into it17:57
J1mor even just disable import of non-impoirted modules in production mode17:57
J1many idea why we are including observable now?17:58
srichterI think the easiest thing is to simply remove apidoc-configure.zcml from package-includes in production mode17:58
srichterno, it should not be there I think17:58
J1mI don't want to distribute a security hole.17:58
J1mMaybe apidoc shouldn't get enabled by default.17:58
srichtermaybe17:59
J1mI don't want to rely on people remembering to disable it.17:59
srichterdo we have a solid definition of "debug mode"?17:59
J1mOf course, it would be better if it was offline. Then this wouldn't have this issue.17:59
J1mI'm not sure17:59
srichterif we do, then we can use the ZCML-condition feature to solve the problem18:00
srichteroffline APIDOC is a 3.2 or 3.3 task ;-) I have thought a lot about it, but I am still lost at how to do it well18:01
srichter(data is not that problematic, but running it as a separate app is18:01
J1mI'm glad it's on your radar.18:01
J1mI need to get going.18:03
J1mlater18:03
srichtersee ya18:03
*** J1m has quit IRC18:03
*** BjornT has quit IRC18:57
*** povbot has joined #zope3-dev19:49
*** jhauser has joined #zope3-dev20:02
*** __gotcha__ has joined #zope3-dev20:08
*** __gotcha__ is now known as __gotcha20:08
*** __gotcha_ has quit IRC20:22
*** bskahan has quit IRC21:30
*** dagnachew has joined #zope3-dev21:39
* dagnachew is away: a plus22:20
SteveAThe|uni: ping22:21
*** lunati1 has joined #zope3-dev22:28
The|unipong22:37
SteveAThe|uni: hi22:44
SteveAso, you reckon that it won't do to leave the authorization policy implementation as totally pluggable in the spec?22:44
*** timte has joined #zope3-dev22:45
The|unisec. phone22:47
The|uniback22:52
The|uniwell. I think so. Because it _appears_ to be so vital that at least I feel uncomfortable leaving it totally open. And I assume the TUV guys to think the same.22:52
The|unii went through the docs and looked at all the places that depend on the specific SP22:53
The|unithere are some goals we want to aim for (e.g. secure delegation) that could be circumvented by an appropriate security policy22:54
The|uniso it's not possible to achieve those goals without a (mutual) supportive construct of the infrastructure and the security policy22:54
SteveAhmm22:54
The|unithen there is a place "fdp_acf.1" which states something like:22:55
SteveAif it is possible, i'd split the thing in two, and say, as a first step let's get the "zope3 with a black box authorization policy" certified, and the get that part alone certified.22:55
The|uniwhat's the black box authorization policy?22:56
SteveAcheckPermission in the "security policy" (should be called authorization policy)22:56
SteveAthe component and stuff that plugs into the rest just there22:56
SteveAi think it makes a clear dividing line in the whole system22:57
The|uniright, it does.22:57
SteveAon one side, you have security proxies, set-up of the server and environment, principals, permissions, code22:57
SteveAon the other side, you have policy, grants databases and whatever else22:57
SteveAand linking them, you have a single API call that returns True or False.22:57
The|unibut still, that fdp_acf.1 function wants rules stated. And I'm not comfortable writing down "shall enforce the rules implemented by the configured authorization policy".22:58
The|unihmm22:58
The|unianyway, let me think about it for a minute22:58
SteveAmaybe mitcon and tuv would be happy to receive two documents: one now, saying "this stuff is plugged in here"22:58
SteveAand one later saying "here's what we'll plug in here, for the certified zope3"22:58
SteveAin the future, the former probably will not change, but the latter certainly will22:59
The|uniok, what is problematic is, that this way decouples quite some information from places where the CC seems to expect them22:59
The|uniYou put a lot of pointers in the functional requirements to a later location.22:59
The|uniThat will make it really hard to read and understand IMHO.22:59
The|uniand actually it makes it even harder to show the consistency of the framework with only pointers around.23:00
The|uni*sigh* :/23:02
SteveAwhat if there's an page you add called "authorization policy" that lists what the authorization policy says about fdp_acf.1 and all the other points where it must say something23:04
SteveAwell, called "zope 3 CC target authorization policy"23:04
SteveAand then, say "shall enforce the decision of the zope3 CC target authorization policy"23:05
SteveAdarn, i need to restart X.23:06
*** SteveA has quit IRC23:06
*** SteveA has joined #zope3-dev23:12
The|uniI'd have to ask the TUV what they think about it23:13
The|uniThe bad thing is that I have to reschedule for the next week again.23:13
The|uniWe just got a new contract and I'm going to be pretty busy starting from tomorrow, so I'll have to do that stuff on the weekends.23:13
*** lunati1 has quit IRC23:14
*** tvon has quit IRC23:14
* dagnachew is back23:15
*** dagnachew has quit IRC23:22
The|uniI'll head off to bed now. I need to talk to the TUV during the week and get more time.23:23
SteveAokay23:23
* The|uni burns happily enjoying the pain.23:23
*** tvon has joined #zope3-dev23:48
*** jhauser has quit IRC23:54
« Saturday, 2005-06-04 Index Monday, 2005-06-06 »

Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!