[Zope-dev] Re: Install doesn't start properly

[Behrens Matt - Grand Rapids]

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 <matt.behrens@kohler.com>
System Analyst, Baker Furniture