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
> 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
> 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
> 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
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
I suppose I should join zope-dev now :-)
Matt Behrens <[EMAIL PROTECTED]>
System Analyst, Baker Furniture
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -