[Zope-dev] Re: WebDAVLocks lost in Control_Panel(was:: [ZPT] how to unlock a webdav locked element ????)
Dieter Maurer writes: ... DavLocks lost in Control_Panel ... It is still in the code App.ApplicationManager.ApplicationManager._objects but objectItems now longer finds it and therefore, it is no longer shown in the control panel. I do not (yet) understand why I found the reason for the missing WebDAV Lock Manager: The Application Manager instance Control_Panel has its own private instance of _objects and does not use that of its class. In this private instance the WebDAV Lock Manager is missing while it is present in the class. This means, nothing serious. Maybe, the Zope maintainers should ensure that the Control_Panel instance has the lock manager. It is obviously useful. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: WebDAVLocks lost in Control_Panel (was:: [ZPT] how to unlock a webdav locked element ????)
The WebDAV manager seems to be invisible only for Zope installations that have been upgraded from 2.3 to 2.4. With a fresh 2.4 installation the WebDAV manager is visible in the control panel. _objects of the ApplicationManager gets initialized only once when Zope gets installed. Because the lock manager has been introduced in 2.4 there is no entry in _objects. Andreas - Original Message - From: Dieter Maurer [EMAIL PROTECTED] To: Robert Rottermann [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, October 21, 2001 12:56 Subject: [Zope-dev] Re: WebDAVLocks lost in Control_Panel (was:: [ZPT] how to unlock a webdav locked element ) Dieter Maurer writes: ... DavLocks lost in Control_Panel ... It is still in the code App.ApplicationManager.ApplicationManager._objects but objectItems now longer finds it and therefore, it is no longer shown in the control panel. I do not (yet) understand why I found the reason for the missing WebDAV Lock Manager: The Application Manager instance Control_Panel has its own private instance of _objects and does not use that of its class. In this private instance the WebDAV Lock Manager is missing while it is present in the class. This means, nothing serious. Maybe, the Zope maintainers should ensure that the Control_Panel instance has the lock manager. It is obviously useful. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone know how to add a property to a Zope Product (not its instances)?
On Saturday 20 October 2001 05:41 pm, Joachim Werner allegedly wrote: 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? This is only half an answer, but maybe it helps: I am not quite sure if you can do that the easy way from Python. (I.e. just define a _properties list). But you certainly can use manage_addProperty: self.Control_Panel.Products.YOURPRODUCT.manage_addProperty(id=TEST, value=TEST ENTRY, type=string) The question is where to put this, probably somewhere in the __init__.py? I don't know if you CAN call it from there. It definitely works from the contructor method of your product, but then the new property will only show up after the first instance has been added ... Joachim AFAIK Zope doesn't officially support meta-data associated with a product in any meaningful way. I have often thought this would be beneficial tho, as it would allow a product to have a global configuration interface in the ZMI that would affect all instances. I think it would be a worthwhile project to think about an API for product preferences. Perhaps this could be added (as tabs I guess) to the exisitng Zope preferences. /---\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association [EMAIL PROTECTED] \---/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: WebDAVLocks lost in Control_Panel (was:: [ZPT] how to unlock a webdav locked element ????)
The CVS contains now a patch to ApplicationManager.py to make the LockManager visible again. Andreas - Original Message - From: Dieter Maurer [EMAIL PROTECTED] To: Robert Rottermann [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, October 21, 2001 12:56 Subject: [Zope-dev] Re: WebDAVLocks lost in Control_Panel (was:: [ZPT] how to unlock a webdav locked element ) Dieter Maurer writes: ... DavLocks lost in Control_Panel ... It is still in the code App.ApplicationManager.ApplicationManager._objects but objectItems now longer finds it and therefore, it is no longer shown in the control panel. I do not (yet) understand why I found the reason for the missing WebDAV Lock Manager: The Application Manager instance Control_Panel has its own private instance of _objects and does not use that of its class. In this private instance the WebDAV Lock Manager is missing while it is present in the class. This means, nothing serious. Maybe, the Zope maintainers should ensure that the Control_Panel instance has the lock manager. It is obviously useful. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Install doesn't start properly
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:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Install doesn't start properly
Martijn Pieters wrote: 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. Okay, as I said, I just didn't care to give the specifics wide publicity if it was going to be problematic for anyone having to rush to get fixes out in the face of details. Incidentally, as far as snipped portions go, it can be safely assumed I'm in agreement with you. On Mon, Oct 22, 2001 at 01:12:33PM -0400, Behrens Matt - Grand Rapids wrote: 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. Yes, it was just a point from the point-of-view of someone who may not know better. Perhaps install should recursively change ownership? 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). The sticky bit doesn't make the directory unwritable, it merely says that new files may be created, but old ones that you don't own may not be destroyed. 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. I maintain the OpenBSD package (which I think will ship with 3.0, hurrah!), and I've solved this by stuffing the distribution into a root-controlled directory, then telling users the way to get Zope up and running is to create a dedicated user, then use a python script I added to the package (zope-instance) which populates an INSTANCE_HOME, creating start/stop scripts, Zope.cgi, inituser, and the like. Of course, back then, the whole port 80 thing was unknown to me. I was operating under the assumption that you front with Apache if you need to bind to 80. Incomplete research on my part. 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). Then we are back to the issue of having nobody be able to read Data.fs, ergo sensitive information in the ZODB compromised in case of a 'nobody' compromise. 'nobody' is counted on by all kinds of UNIX daemons to not have any sensitive permission, read _or_ write, in case of compromise. And actually, it looks like Data.fs is read in *before* the nobody drop. I had Data.fs root-owned with mode 600 (r/w only by owner) and Zope started fine. It was packing that was a problem. 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. No problems with not setting it, or no problems with telling people to set it? If it's the former, having umask 022 means I can waltz on in as any user on the system and read any newly-created file in var, including Data.fs after it's packed the first time. pack doesn't worry about file modes. I suppose I should join zope-dev now :-) -- Matt Behrens [EMAIL PROTECTED] System Analyst, Baker Furniture ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] IE and Zope MIME type handling
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 [EMAIL PROTECTED] \---/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] IE and Zope MIME type handling
I agree with solution #2. When I upload a .xls file from Mozilla on Linux, it also says that it is application/octet-stream. Even more annoying: Netscape 4.7.x says that it is application/vnd.ms-excel, while Konqueror says application/ms-excel for the same file. For sites that want to enforce, it makes me think that it might be better to do #2 even for non octet mime types. -Paul Casey Duncan wrote: 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 [EMAIL PROTECTED] \---/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] IE and Zope MIME type handling
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. Em Monday 22 October 2001 16:33, Casey Duncan escreveu: 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 [EMAIL PROTECTED] \---/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- Sidnei da Silva X3ng Consultoria e Desenvolvimento Ltda. [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
