[Zope-dev] Re: I want to fix App.Management.Tabs.manage_workspace

[Chris Withers]

Casey Duncan wrote:
>>1. manage_workspace is only protected by the Authenticated role, and
>>that is done directly, not even through a permission.
> 
> 
> I think that is probably because this method is an abstraction for the
> default managment screen. It does not know what the correct permission
> is, but assumes you at least must be logged in to see any management
> screen.
> 
> What are you suggesting to do about this?

My current thinking is "I don't know" ;-) I'm hoping discussion here can firm 
that up a bit...

>>2. self.filtered_manage_roles then limits the options of what can be
>>shown, which might end up being nothing. But, because the method is
>>only protected by 'Authenticated', no chance is given to specify other
>>user credentials (say, from a user folder higher up in the tree) which
>>might be able to see something.
> 
> Can you give a concrete use case for what you describe?

See below...

>>3. There's a bare try/except which masks errors. From what I can see,
>>it should ONLY catch IndexError's.
> 
> Yep, bare excepts == bad. Kill it.

Will do :-)

>>5. The Unauthorized could raise a more helpful message "You are not
>>authorized to view an of this object's management itnerface"
> 
> -0, I think it may be better to say nothing which discloses less
> information to would-be attackers. Perhaps VerboseSecurity might be able
> to elaborate, I dunno.

I don't understand VerboseSecurity enough to make this happen. Since the error 
message is already different from a "real" auth error, I'd say that 
vulnerability is already there, and so making it more informative to people it 
might help is not going to make Zope less secure...

>>The semantics I want are: "Show the 1st management tab the user is
>>allowed to see, if they're not allowed to see anything, check if a
>>user of the same name further up the userfolder tree can see anything"
> 
> Why? Is this consistent with behavior elsewhere? 

It's consistent with how Zope userfolders work, yes...

> Are you concerned that
> lower user folders could lock out global managers by creating
> non-privileged users with the same name locally?

Exactly. And since I did this to myself only to spend a morning going "huh?", I 
figure this code is not quite right...

> 2.7 and the HEAD are likely suspects for bug fixes. I doubt there will
> be another 2.6 release.

Righty, so, now just to figure out what to do...

Chris

PS: Are there any unit test for this? har har har har...

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk