October 2001 - Zope-Dev

Re: Install doesn't start properly
by Martijn Pieters 24 Oct '01

24 Oct '01

Please keep the mailing lists in the loop. I do not control the Zope source, and others may have an opinion as well. I am CC-ing Zope-Dev on this as this discussion is more appropriate there. On Mon, Oct 22, 2001 at 01:12:33PM -0400, Behrens Matt - Grand Rapids wrote: > > The above URL confuses running as nobody and having the files owned by > > nobody. > > It is not terribly clear, and it reflects a shallower understanding of > the problem that I used to have. So I dragged out a bindist, untarred > it as root, and performed a few experiments, see below. > > > Files should be owned by root (which it would do if installed as root) > > and you can run as nobody, provided that nobody has permission to write > > to the var directory. > > First, actually, untarring as root sets the ownership of a lot of the > stuff in my solaris bindist to 506:100 (brian:users, it says in the > listing.) Default behaviour when using tar as root; it'll preserve the UID and GID of the person that created the tar. > When I first went on my "nobody" crusade I was under the assumption that > "nobody" needed to be able to rw Data.fs as well. That should probably > be clarified when advice is given to make "var" nobody-writable. I'm > guessing there are more than a few people who take "make var > nobody-writable" as requiring that files inside it also are > nobody-writable. Maybe this is not anyone's responsibility but I don't > want to give someone who doesn't know any better incomplete advice. > > In any event, the drop-to-nobody setup is still not perfect, though. > Here are a few examples I just tested now: > > 1. "nobody" can change Z2.pid since it owns it; this can be used to > trick root into killing an arbitrary process. Solution: Z2.pid should > be written before the setuid call. Agreed. > 2. "nobody" can arbitrarily destroy and replace any file in var, still > leaving the possibility open for mischief. Writable directories mean > you can rename, remove, etc. Solution: The sticky bit could get around > this. I don't see how? What is the point of having one writeble directory for the process and then make it unwritable? The point of the var directory is to have only one place where the server process can do all its writing (which it needs to be able to do in order to operate). Note that if you feel uncomfortable with the user 'nobody', you can also dictate that Zope switches to another UID. On Debian www-data is used, for example. > 3. Packing doesn't work unless "nobody" can read Data.fs. Letting > "nobody" read Data.fs nullifies most of the security we gained. If we > do let "nobody" read Data.fs, then when packing is performed we end up > with a nobody-owned Data.fs. Nobody will have to be able to read Data.fs, otherwise the whole Zope process wouldn't work! Same for writing. The only way around this is having a separate server process control the writing (ZEO), or not run as root (and have another process like Apache provide port 80). > 4. Anything else that uses var, such as gadfly, ends up nobody-owned. > I don't see any programmatic way around this. Putting sensitive data in > gadfly is downright silly IMO, but in a general-use platform, I don't > control what people do. Default to secure, if the end-user overrides > our security, it's their fault if something is compromised. I think we make it pretty clear that Gadfly is for demo purposes only, and it isn't useful for any critical data for many more reasons. > Not really "nobody"-related but still of note: with the default UNIX > umask, new files (i.e. packed Data.fs) are created with read permissions > for group and other. I don't see a recommendation to set umask 077 > anywhere but I may just be missing it. I don't think there will be any problems with this. > I know I'm being a pain in the arse, but this stuff is pretty important, > I think. I'd like to get it fixed up, and I'm happy to help with code > or doc changes or whatever, as well as keeping the specifics under wraps > until a fix is committed. In the meantime I think it's still best and > will keep recommending that people run their installs as dedicated users. The best way of having things changed you care about, is to submit patches and bug reports, especially if they are this detailed. Unfortunately, the bug collector is down right now (Ken Manheimer is working very hard on a replacement), but any suggestions are certainly still welcome, preferably to the mailinglists. -- Martijn Pieters | Software Engineer mailto:mj@zope.com | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------

3 3

problem to rename folder
by Johan Beauce 24 Oct '01

24 Oct '01

Hello, I have a little problem. I use this function to rename an object in my site (file or folder). It work perfectly with file but I have an error when I try to rename a folder .... I think the error is from "PARENT[0]", so do you have a solution ??? <dtml-let objRename="_.getattr(PARENTS[0], _['idName'])"> <dtml-call "objRename.manage_renameObjects([idName],[newId],getWay(REQUEST.PATH_INFO))" > </dtml-let> Thanks a lot, Johan. ---------------------------------------------------------------------- ---------------------------------------------------------------------- >> This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to whom they are addressed. >> Any unauthorised copying, disclosure, or distribution of the material within this email is strictly forbidden. >> Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Odyssey Asset Management Systems SA unless otherwise specifically stated. >> An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. >>If you have received this email in error, please notify the sender immediately and delete the original.

2 1

Versions (still)
by Andy McKay 23 Oct '01

23 Oct '01

So there I was in this discussion about Zope versioning (again) and there were two features requested that seemed perfectly reasonable at the time, - to have a list of all the objects changed by a version - to be able to individually commit or discard changes in a version on a per object basis This is would be extremely useful for those times when you forget to check out of a version and accidentally lock the root folder (This happens quite a bit). Simple I thought, but ugh versions go all the way down to FileStorage and got into ZODB stuff I didnt understand. I would have thought having a little refactoring to give two more methods: getVersionContents and commitObject would be possible, but Im scratching my head at FileStorage now. Before I embark down this path is there an easier way? Cheers. -- Andy McKay.

3 4

FYI: Zope version control project
by Brian Lloyd 23 Oct '01

23 Oct '01

Hi all - We've started a new fishbowl project to address version control in Zope: http://dev.zope.org/Projects/Wikis/DevSite/Projects/ZopeVersionControl/ It's still early in the process of initial artifacts, but we know that this is an issue dear to many hearts, so I wanted to let folks know about it as early as possible to get the feedback started on the initial proposal and risk list. Brian Lloyd brian(a)zope.com Software Engineer 540.361.1716 Zope Corporation http://www.zope.com

3 2

Zope 2.4.2 Error
by E. Seifert 23 Oct '01

23 Oct '01

Hi list, I just installed the 2.4.2 update over my Linux Zope 2.4.1 and I get the following traceback: Traceback (innermost last): File /usr/local/zope/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /usr/local/zope/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/zope/lib/python/Zope/__init__.py, line 226, in zpublisher_exception_hook (Object: de) File /usr/local/zope/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/zope/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: index_html) File /usr/local/zope/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: index_html) File /usr/local/zope/lib/python/OFS/DTMLDocument.py, line 199, in __call__ (Object: index_html) File /usr/local/zope/lib/python/DocumentTemplate/DT_String.py, line 546, in __call__ (Object: index_html) File /usr/local/zope/lib/python/OFS/DTMLMethod.py, line 188, in __call__ (Object: standard_html_header) File /usr/local/zope/lib/python/DocumentTemplate/DT_String.py, line 546, in __call__ (Object: standard_html_header) File /usr/local/zope/lib/python/Products/Renderable/Renderable.py, line 17, in __str__ (Object: standard_site_menue) File /usr/local/zope/lib/python/OFS/DTMLMethod.py, line 195, in __call__ (Object: render) File /usr/local/zope/lib/python/DocumentTemplate/DT_String.py, line 546, in __call__ (Object: render) File /usr/local/zope/lib/python/DocumentTemplate/DT_In.py, line 770, in renderwob (Object: objectValues(['SimpleNav Element'])) File /usr/local/zope/lib/python/Products/Renderable/Renderable.py, line 17, in __str__ (Object: ab) File /usr/local/zope/lib/python/OFS/DTMLMethod.py, line 203, in __call__ (Object: render) KeyError: validate Is there someone who can help me? TIA Erich

3 4

Re: [Zope-dev] IE and Zope MIME type handling
by Oliver Bleutgen 23 Oct '01

23 Oct '01

> It is possible, as far as i know, to use the unix command "file -bi > <filename>" and parse the returned result. It works very fine, but, > unfortunatedly ;^)) just on Unix/Linux/*nix. Have read this on the [Zope] > list and tested myself. This is not quite correct, http://sources.redhat.com/cygwin/ At least the cygwin UNIX for win environment includes file(1). So this should work on any plattform where zope works. cheers, oliver

1 0

IE and Zope MIME type handling
by Casey Duncan 22 Oct '01

22 Oct '01

Problem: Getting Zope to properly detect MIME types of posted files The current solution is to try the following methods: 1. See if the browser specified a type and if so, use it. 2. See if the file extension can be recognized and derive a mime-type from it 3. Do some inspection of the file data (limited to text files at present) Obviously #1 is preferred, and anytime the browser supplies the mime type, method #2 and #3 are never used. However, I have found a problem with this. Sometimes, IE reports a mime-type of "application/octet-stream" on files that is doesn't know better about. This specifically happens on WordPerfect files. Now, I am as shocked as you are that a competitor's file format would not be recognized by IE, however, difficult as this may be to believe, it appears to be true. My proposed solution and change in behavior is to ignore the browser supplied type if it is "application/octet-stream" and use #2 and perhaps #3 in that case to delve in further. Obviously this may pose a problem for applications that rely on the mime-type for files with extensions that might otherwise indicate something else. But since this behavior seems restricted to IE (amongst the browsers I tested), I doubt it would cause harm or breakage. Thoughts? I will supply the necessary patches if there is no objection. /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan(a)nlada.org \---------------------------------------------------/

3 2

Anyone know how to add a property to a Zope Product (not its instances)?
by Craeg K. Strong 22 Oct '01

22 Oct '01

I am developing a new Zope product in python. Normally one adds properties to a product like so: class newProduct(SimpleItem, etc): meta_type 'NewProduct' _properties = ( {'id': 'title', 'type':'string'}, { 'id':'description', 'type':'string'}, {'id':'foobar' , 'type':'string'"}, ) . . . This defines properties for instances of the new Product. But I want to add properties for the product itself. These properties would show up in the property sheet of the PRODUCT, not its instances-- ie in Root Folder/Control_Panel/Products/NewProduct on the Properties tab. By default, Zope adds the title and version properties, for which it gets the value from version.txt and meta_type, but does anyone know a way to add more? Thanks in advance, --Craeg

3 2

Re: International Objects
by Tim McLaughlin 22 Oct '01

22 Oct '01

Roger, I've identified a serious weirdness that causes InternationalObjects not to work. It's this... InternationalObjects - works on 2.4.0 and 2.4.0 upgraded to 2.4.1 but does not work on clean 2.4.1 install. This indicates an disconnect between the upgrade and clean install paths (at least that's my first thought). Zope-devers, any ideas? Anybody know of any __getattr__ changes in the 2.4.0 to 2.4.1 transition? Cheers, Tim Roger Espinosa wrote: > > On Wed, 17 Oct 2001, Tim McLaughlin wrote: > > > > > If so, let me know what you think after you toy with it a bit. Note > > that it also works with ZClass props :) > > > > Still persisting, as the more I dwell on it, the more I like this approach > --- one of the reasons I'm using Zope is the ease of mixing complicated > code with simpler code (handy for the education environment), and this > approach fits that ideal. > > At any rate --- I continue to fail if I try the monkeypatch; oddly, if I > do this bit of code: > > x = Item() > print Item.__getattr__(x, 'DEBUG') > > it'll correctly work, but > > x.DEBUG > > seems to skip it altogether; I even assigned the InternationalObjects > __getattr__ to an unrelated method (e.g. Item.fetchValueForKey = > __getattr__) and *that* works, which sure looks like something else is > hijacking __getattr__. > > Except when I just go patch the code into OFS.SimpleItem (I'm already > hacking get_request, so what the heck :)...it works as hoped. (Which would > tend to discount the hijacked __getattr__ business.) > > Anyway, neat idea :) > > Roger -- Tim McLaughlin iterationZERO - www.iterationzero.com 703.481.2233

1 0

ComputedAttribute, Persitent and "too many datafull base classes"
by Godefroid Chapelle 21 Oct '01

21 Oct '01

Hi, In a product I am writing, I am trying to add a ComputedAttribute to an instance of a Folder descendant class. This is the code I use: def addComputedAttribute(self, attributeName, sourceCode): methodName = '_ca_get%s' % attributeName self.addMethod(methodName, sourceCode) setattr(self, attributeName, ContextComputedAttribute(self.__class__.__dict__[methodName])) where at first I defined ContextComputed Attribute like this: import ComputedAttribute _ComputedAttribute = ComputedAttribute.ComputedAttribute del ComputedAttribute class ContextComputedAttribute(_ComputedAttribute): pass This put the Folder in a bad state : when I access it later, the Zope instance crashes. So I supposed I needed to use a persistent Attribute and I tried with ContextComputedAttribute class defined like this: class ContextComputedAttribute(Persistent): def __init__(self, test): pass In this case, the Folder stays in a good state but it does not fullfill the requirements as ContextComputedAttribute does not descend from the real Zope ComputedAttribute class. My problem is the following : I cannot define a class like this: import ComputedAttribute _ComputedAttribute = ComputedAttribute.ComputedAttribute del ComputedAttribute class ContextComputedAttribute(_ComputedAttribute, Persistent): pass In this case, I get the following error TypeError: too many datafull base classes which has to do with too many ExtensionClass derivation... Can someone tell me how to define a class with both ComputedAttribute and Persistent behaviours ? Thanks a lot. -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 30 1348 Louvain-la-Neuve Belgium Tel + 32 (10) 457490 Mob + 32 (477) 363942 TVA 467 093 008 RC Niv 49849

2 1