[Zope-dev] Methods through the Web (security?)

Thu, 18 May 2000 10:04:36 -0400

Chris Withers <chrisw@nipltd.com> opined:
> 
> Brian Lloyd wrote:
> 
> [snip]
> 
> > > Won't this break Amos' XML-RPC-based editor and similar hacks?
> >
> > Waaa.... probably. Ok, so I've _provisionally_ changed this in
> > the current CVS. I feel a to-the-death-cage-match coming on.
> 
> Horse before the cart?
> 
> Maybe the XML-RPC editor needs fixing 'cos something got fixed in
> Zope?!
> 
> > > Can't you just turn off 'Access contents information' permission
> > > or whatever it is on a folder if you don't want people to call
> > > those things trough the web?
> >
> > Yes you could, except that you would also make them inaccessible
> > from DTML (or from anywhere else) for the same class of users.
> 
> ...as I found out when I first ran into this problem...
> 
> ...and as I said in the first post you can get round this using a
> tortuous set of proxy roles (dunno how that'll get screwed up in 2.2)
> but it's not a 'nice' solution to what should be a fairly simple
> problem.
> 
> > Is it really acceptable that in order to use <dtml-in objectIds>
> > on a page that needs to be accessible to anonymous users that I
> > must grant 'Access contents information' to anonymous users and
> > thus give them the ability to inspect my objects if they want to?
> 
> No!!! ;-)

I don't get the issue here, I guess;  either anonymous users can view
objectIds (through the web, through XML-RPC, whatever), or they can't
(because you don't want them to have the information that a given
object is there, I guess?)  If they can't, then _any_ DTML method
which calls objectIds() should be required to have non-anonymous
permissions, either through the AUTHENTICATED_USER or through proxy
roles.  This seems to be working as designed in the current
implementation.  Turning off objectIds() by default is like running
an anonymous FTP server but disallowing the "dir" command:  it reduces
the utility of the server to such an extent that you might as well
not bother. :)

An alternate implementation would be to have objectIds() check for the
anonymous role, and return only the subset of IDs that the
'skip-unauthorized' attribute filters in <dtml-in> (this touches on
another peeve of mine -- lots of the "magic" which DTML does is not
accessible outside of the tags).

> The solution I proposed before is simple (maybe not to implement ;-)
> and  I think solves all the problems:
> 
> Split the current 'view' permission into two new permissions:
>
> 1. View - allow users to directly access an object through
> HTTP/FTP/XML-RPC/etc
>
> 2. Execute - allow non-direct execution of a method by a user, for
> example by them viewing another method/object which they have the
> 'view' permission for.
> 
> This effectively provides the same functionality as adding or removing
> a docstring from a method in a python class, and could be used to
> replace it, as it's not really documented anywhere.
> 
> I can't really see a use for he 'Access contents information'
> permission other than an additional control over and above these two
> new ones.
> 
> As simple example:
> -index_html (role X has view permission)
> <dtml-var standard_html_header>
> Some Text
> </BODY></HTML>
> 
> -standard_html_header (role X has execute but not view permission)
> <HTML><BODY>
> 
> So, a user with role X can view index_html and have it render
> properly (although it wouldn't if he didn't have the execute
> permission on standard_html_header) but if the user tried to view
> standard_html_header on its own, he would get an unauthorised
> error...
> 
> Comments? (hopefully I'll get some this time... ;-)
> 
> cheers,
> 
> Chris
> 
> PS: The XML-RPC stuff could just be given the nwe view permission for
> objectIds, if it REALLY needs it... although this would mean the
> docstrings thing would have to eb replaced, which isn't necessarily a
> bad thing ;-)

Itamar Shtull-Trauring <itamar@maxnm.com> replied:

> Yes, it really needs it.  My XML-RPC uploading interface to Zope
> needs to know what's in a folder - so it needs objectIds.  How else
> am I supposed to browse through the Zope tree?  I could have users
> install a method, but this is a very generic need (browsing the
> object tree) and should be built in.

Steve Alexander <steve@cat-box.net> chimed it:

> It occurs to me that there are two distinct "views" of the Zope tree.
> 
>  1. The developer's / content manager's view
> 
>     This is what we have now.
> 
>  2. The end-user's view
> 
>     Taking HTTP as an example, this consists of the set of URLs that
>     are available for access via the web. Other URLs should return a
>     404 Not Found, even if they are available as part of the
>     developer's view (point 1).
> 
> Taking HTTP alone, for simplicity of expression; I suppose what I'm
> asking for is that there are two HTTP servers for one Zope instance.
> The one on port 80 (for example) only responds to those URLs that are
> for public viewing. The one on port 8081 (for example) responds to
> any request that makes sense to map onto an object or attribute.
> 
> The same scheme can be applied to FTP -- you choose whether a
> particular FTP server presents the "public" view, or the "developer"
> view.

I'm presuming you mean to disallow anonymous access to the "developer"
view -- otherwise, you have just transferred the
"security-through-obscurity" to another location.  Providing dual
HTTP servers is actually useful in another way -- it allows you to
both develop and test from within the same browser session, without
sharing credentials.  Patches accepted :)  (hint:  look at how z2.py
initializes the HTTP server).

Tres.
-- 
=========================================================
Tres Seaver  tseaver@digicool.com
Digital Creations  "Makers of Zope"  http://www.zope.org