RE: [Zope-dev] Methods through the Web (security?)
Hmm, another ZAZ fan :-)
Don't get me started... :^)
a holdover from the bobo days - if you are a method and you have a docstring, you are accessible through the web (but still subject to the std security rules). objectIds and objectValues are a good example of things that really only want to be used from DTML and thus shouldn't have docstrings. I've changed this (and a few other iffy methods) for the next release.
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.
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. 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? I have a feeling that intent will need to become more important somehow in the future. As we add more protocols and types of usage to Zope, it becomes harder for a single permission to really cover a resource in a way that makes sense for all of the various usages. From the point of view of an xml-rpc based client app, having objectIds and the like may be an absolute necessity, while from a pure HTTP standpoint many would at best consider it superfluous or at worst consider it a security hole. *sigh*. Maybe the right short-term thing is to just leave it the way it was and tell people who may be concerned about it to turn it off via that permission and live the repercussions that will have in their DTML. I guess at least that way the software isn't taking the choice out of their hands. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
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!!! ;-) 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 ;-)
Chris Withers wrote:
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 ;-)
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. -- Itamar S.T. itamar@maxnm.com
Itamar Shtull-Trauring wrote:
Chris Withers wrote:
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 ;-)
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.
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. -- Steve Alexander Software Engineer Cat-Box limited
At 12:13 PM 5/18/00 +0100, Steve Alexander wrote:
It occurs to me that there are two distinct "views" of the Zope tree.
1. The developer's / content manager's view
2. The end-user's view
Unfortunately, it's not just black-and-white, it's lots of shades of grey in between. Management screens, for example, display tabs based on a user's permissions. You can give someone certain permissions and not others. It's very difficult to say, at the Zope framework level that something is "development" vs. "content". In some ways it'd be nice if you could, because then you could use permission mappings for "runtime" permissions on all of your methods, and have roles mapped to permissions in "development" mode. (Sort of the way ZClasses work now - when you edit the ZClass, you're in "development", but when you access an instance, it's "runtime" as far as permissions are concerned.)
Chris Withers wrote:
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.
[snip]
Comments? (hopefully I'll get some this time... ;-)
Various things. What you'd need is turn off 'view' permission by default for just about *everything* except possibly DTML Documents, otherwise it's just too easy to set up a site that exposes too much. Exposure to URLs should be turned off by default. Everything would still have 'execute' permission, so I don't think that should be a permission at all, as everything really has it and nothing can do without it anyway. Anyway, see my other posts. I think you would need to do something like this: 'view' and 'access' merge into a single thing called 'access'. 'access' then gets split into 'access through URL', 'access through FTP', 'access through XML-RPC'. By default, 'access through URL' is turned *off* for anonymous surfers for all objects. You need to turn this on explicitly. Note that you quickly overestimate the amount of cases this needs to be done. In fact, I think in the site I have in production use here, there's just one or two index_html's that need to be given 'access through URL' permission. :) The tricky bit is if you want methods on objects that *are* accessible through URLs. There doesn't seem to be a good way to do that now, but the question is if you really ever want that in a site. You usually only call such methods from DTML. Regards, Martijn
Martijn Faassen wrote:
Various things. What you'd need is turn off 'view' permission by default for just about *everything* except possibly DTML Documents, otherwise it's just too easy to set up a site that exposes too much. Exposure to URLs should be turned off by default.
Well, this is why doing it with permissions is great because you can set it to your preference in the root folder and aquire it from there onwards...
Everything would still have 'execute' permission, so I don't think that should be a permission at all, as everything really has it and nothing can do without it anyway.
Yes, but you may want to restrict WHO can execute something. Perhaps you have a method that only managers should be able to execute, and no-one should be able to 'view'.
'view' and 'access' merge into a single thing called 'access'.
I still don't really see any point in the 'access' permission and, in fact I've just been bitten badly by it (see my RecentChanges post to the Zope list...)
the question is if you really ever want that in a site. You usually only call such methods from DTML.
Not so, try out ZWiki's ;-) I notice there is an FTP permission already. Maybe there should be: - an execute permission - a 'view' permission for each 'server': HTTP, FTP, XML-RPC... cheers, Chris
Brian Lloyd wrote:
Yes you could, except that you would also make them inaccessible from DTML (or from anywhere else) for the same class of users.
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?
So you have something like: 'Access at all' (this is 'Access Contents Information') 'Access through URL' (the 'expose' flag I talked about in previous posts) 'Access through FTP' 'Access through XML-RPC' etc. This would be for individual Zope objects. For objects that expose methods, perhaps you'd need yet another permission, something like: 'Access methods at all' 'Access methods through URL' .. Of course this sounds like it could get unwieldy, unless there was some clear user interface.
I have a feeling that intent will need to become more important somehow in the future. As we add more protocols and types of usage to Zope, it becomes harder for a single permission to really cover a resource in a way that makes sense for all of the various usages.
Right.
From the point of view of an xml-rpc based client app, having objectIds and the like may be an absolute necessity, while from a pure HTTP standpoint many would at best consider it superfluous or at worst consider it a security hole.
*sigh*. Maybe the right short-term thing is to just leave it the way it was and tell people who may be concerned about it to turn it off via that permission and live the repercussions that will have in their DTML. I guess at least that way the software isn't taking the choice out of their hands.
Um, is there a good workaround then, if you turn it off? I mean, if you turn off 'Access Contents Information' *and* you want a DTML method that generates an index of all subfolders, what do you do? Work with proxies? Regards, Martijn
Martijn Faassen wrote:
So you have something like:
[snip]
Of course this sounds like it could get unwieldy, unless there was some clear user interface.
This would be unwieldy, I prefer the suggestion I made (obviously ;-) which gets around this...
From the point of view of an xml-rpc based client app, having objectIds and the like may be an absolute necessity, while from a pure HTTP standpoint many would at best consider it superfluous or at worst consider it a security hole.
Well, yes, but its the same problem no matter what your protocol: Should a user be able to do something with a method or should a method used by user be able to do something with a method? The second case, the use is defined by the person who wrote the application, the first case it's defined by the (possibly malicious) user... This sounds a lot like proxy roles, I know, but they'er just to clumsy for this special case...
Um, is there a good workaround then, if you turn it off? I mean, if you turn off 'Access Contents Information' *and* you want a DTML method that generates an index of all subfolders, what do you do? Work with proxies?
Yes, lots of them and in a very complicated fashion which is easy to screw up and so defeat the point of doing it in the first place ;-) cynically, Chris PS: I'll try and cheer up later :S
Martijn Faassen wrote:
Brian Lloyd wrote:
Yes you could, except that you would also make them inaccessible from DTML (or from anywhere else) for the same class of users.
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?
So you have something like:
'Access at all' (this is 'Access Contents Information')
'Access through URL' (the 'expose' flag I talked about in previous posts)
'Access through FTP'
'Access through XML-RPC'
etc.
This is an interesting idea -- The Zope server is an Object database that exposes objects and attributes via various protocol modules. I can see a future where you'd want to be able to plug in arbitrary protocol modules -- and perhaps more than one instance of each type of protocol (for example, http on ports 80 and 8080). It would make sense to me for each protocol to have its own set of "expose flags" or even "expose rules" for each addressable object/attribute. The user interface to manage the objects could collect these all into one place, so as the manager of an object, you can decide what is allowed to be seen via which protocols. -- Steve Alexander Software Engineer Cat-Box limited
On Thu, 18 May 2000 16:55:37 +0200, Martijn Faassen <faassen@vet.uu.nl> wrote:
Brian Lloyd wrote:
Yes you could, except that you would also make them inaccessible from DTML (or from anywhere else) for the same class of users.
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?
So you have something like:
'Access at all' (this is 'Access Contents Information')
'Access through URL' (the 'expose' flag I talked about in previous posts)
'Access through FTP'
'Access through XML-RPC'
It sounds like what you really want is the ability to provide a different Anonymous User objects, based on how the user is accessing the server. You could have separate "Anonymous RPC User", "Anonymous FTP User" etc, and use the existing mechanism to give different permissions to each user. Toby Dickenson tdickenson@geminidataloggers.com
participants (8)
-
Brian Lloyd -
Chris Withers -
Itamar Shtull-Trauring -
Martijn Faassen -
Phillip J. Eby -
Steve Alexander -
Steve Alexander -
Toby Dickenson