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

[Martijn Pieters]

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/
---------------------------------------------