[Zope-dev] Bug Day June 2002 results
I just wanted to give a quick summary of Bug Day June 2002, and get people thinking about July 2002 a little sooner so maybe more people can make it. Yeah, I know there were a lot of things going on this time around... Anyway, we fixed #151, #72, #6, #402, #79, #272, #409, #312, and #432, plus chrism@ worked tirelessly on the Transience problems. Total bugs resolved, then, is 10. Next Bug Day, provided folks are keen on it, would then be Thursday, July 18 (IIRC, the Europeans preferred Thursdays), starting at 9 AM US/Eastern. ___ 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] How about a Bug Day this Friday?
Brian Lloyd wrote: We are planning to have the inaugural bug day this Friday (April 12th) from around 9 a.m. US /Eastern until we've all had enough :^) Sounds good. Make it #zope-dev, as nothing ever happens there :-) ___ 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] Zope 2.6 planning - call for contributors!
Behrens Matt - Grand Rapids wrote: This isn't exciting by any means unless you're one of the people who package Zope up for distribution, or maybe you're one of the people who manage lots of little Zopes on one system; but I'd like to revive the grand unified Zope installation and control proposal that has been floated by many people (including me) in one form or another for some time FYI, everyone who's following this: I have hijacked http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration for this purpose. :-) ___ 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] Zope 2.6 planning - call for contributors!
Brian Lloyd wrote: Let's get a discussion started to define 2.6. This isn't exciting by any means unless you're one of the people who package Zope up for distribution, or maybe you're one of the people who manage lots of little Zopes on one system; but I'd like to revive the grand unified Zope installation and control proposal that has been floated by many people (including me) in one form or another for some time. Wikiwise, this would wrap up http://dev.zope.org/Wikis/DevSite/Proposals/ZopeStartupProvisions and http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration, at least. To summarize, this would involve - an expanded build program with an installation scheme that would allow multiple versions of Zope to be present on the same system - making that installation 'secure by default' - a registry of Zope installations and one of instances and their configuration settings - a 'zopectl' program or similar that would be able to start and stop instances - a 'zopeinstance' program or similar that would become the _recommended_ way of setting up Zope, by creating an INSTANCE_HOME It would be nice if - the same framework could apply to Zope 3, maybe taking care of that piece ahead of time I'm more than willing to head this up, though I question how long we have before 2.6 to do so. ___ 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] product distribution compliance
The TTW Product distribution tab is not compliant with http://www.zope.org/Wikis/DevSite/Proposals/FinishedProductGuidelines. Products/..., not lib/python/Products/... is what it should be doing. The attached patch makes it so. Incidentally, where are we supposed to be sending patches? Trawling recent mailing list archives comes up with several conflicting answers. klm@, ColDev, the ML...? -- Matt Behrens [EMAIL PROTECTED] System Analyst, Baker Furniture Product_py.patch.gz
Re: [Zope-dev] login prompt after letting user change his password.
Clark OBrien wrote: Hi all I have written some code to alow a user to change his password (below) The problem is that after executing this code the login dialog pops up. The login requires the user to enter his NEW password. There is absolutely nothing wrong with that. Basic authentication works by sending the username and password with each request. You've changed the password on the server, but the client is still sending the old password, which doesn't authenticate them any longer. The user'd have to do it sometime, why not right after their password is changed? BTW, the proper forum for this type of question is the main Zope mailing list, [EMAIL PROTECTED]. -- 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 )
Re: [Zope-dev] Re: Install doesn't start properly
R. David Murray wrote: On Mon, 22 Oct 2001, Martijn Pieters wrote: 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. Just FYI, this works right (IMO) under FreeBSD: files untarred as root are owned by root unless you use the p flag. Of course, this note only applies if you are just handling this item via doc changes; if you have install do the chown, it's moot. I'm still wrestling with myself over whether or not this is an issue that needs to be addressed by the install script. On one hand, it really is the administrator's responsibility to check ownership and permissions. On the other hand, just about every other mature open source package out there installs and operates somewhere *other* than its source tree, setting permissions and ownerships as it goes. :-/ I will probably add it to the massive patch I'm working on and see what kind of reception it gets... (ObMozillaBug: while I was typing the first paragraph, a display bug showed me that I was, in fact, wrestling with my elf.) -- 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] startup security status (say that five times fast... well, ok, it wasn't so tough after all)
I have a patch in hand that addresses MOST of the issues I brought up, but the biggie (tricking root into killing arbitrary processes) is a hard one to solve. I have many options, and I'd like opinions... Right now, the pid file is written out by the user that ZServer drops to after starting. This is bad because if that user is compromised, the pid file can be overwritten, and root can be tricked into killing (an) arbitrary process(es) the next time 'stop' is run. The obvious solution was to move the writing of the file up before the setuid() call. Now, the unprivileged user can't *change* the pid file. However, because the var directory must be writable by the unprivileged user, the unprivileged user can *remove* then *rewrite* the pid file, and we're back where we started. Solutions: 1. Have the stop script check ownership of the pid file to make sure it's still root's baby. This solution seems easiest, but something about it doesn't seem right to me. When something doesn't feel right to me, there's probably a way to fool it... 2. Enforce the sticky bit on the var directory. From Solaris' chmod(2) manpage: If a directory is writable and has S_ISVTX (the sticky bit) set, files within that directory can be removed or renamed only if one or more of the following is true (see unlink(2) and rename(2)): o the user owns the file o the user owns the directory o the file is writable by the user o the user is a privileged user (Privileged user means 'root'.) We only need to enforce the sticky bit if we start as root and are doing the requisite setuid(). My patch already has a test for this. 3. Have the pid file written into another directory that only root can write to. The rest of this should probably be another mail, but I figured I'd cover what my patch also does: 1. No longer defaults to running as 'nobody'. As I've explained, running as 'nobody' and the requisite permission settings that need to go with running as 'nobody' can set your Zope data up for compromise on your local system. If -u is not specified z2.py will SystemExit. 2. Warns you if you decide that you REALLY want to run as 'nobody', either with -u or by being nobody when starting z2. 3. Tells you when and who it actually setuid()s to. 4. Warns you if your umask isn't sufficient to protect your data files (experiment: pack your Data.fs and check its permissions.) All messages in this patch are going through zLOG for cleanliness' sake. -- 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 )
Re: [Zope-dev] startup security status (say that five times fast... well, ok, it wasn't so tough after all)
I opted for #2, since it requires no changes to existing start/stop scripts. 2. Enforce the sticky bit on the var directory. From Solaris' chmod(2) manpage: If a directory is writable and has S_ISVTX (the sticky bit) set, files within that directory can be removed or renamed only if one or more of the following is true (see unlink(2) and rename(2)): o the user owns the file o the user owns the directory o the file is writable by the user o the user is a privileged user (Privileged user means 'root'.) We only need to enforce the sticky bit if we start as root and are doing the requisite setuid(). My patch already has a test for this. Patch is attached, against the current release. (diff -c, God bless Solaris... heh) -- Matt Behrens [EMAIL PROTECTED] System Analyst, Baker Furniture z2_py.diff.gz
Re: [Zope-dev] startup security status (say that five times fast... well, ok, it wasn't so tough after all)
I opted for #2, since it requires no changes to existing start/stop scripts. 2. Enforce the sticky bit on the var directory. From Solaris' chmod(2) manpage: If a directory is writable and has S_ISVTX (the sticky bit) set, files within that directory can be removed or renamed only if one or more of the following is true (see unlink(2) and rename(2)): o the user owns the file o the user owns the directory o the file is writable by the user o the user is a privileged user (Privileged user means 'root'.) We only need to enforce the sticky bit if we start as root and are doing the requisite setuid(). My patch already has a test for this. Patch is attached, against the current release. (diff -c, God bless Solaris... heh) -- Matt Behrens [EMAIL PROTECTED] System Analyst, Baker Furniture z2_py.diff.gz
[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 )
