[ZCM] [ZC] 2055/ 7 Edit "drop privileges before creating zopectlsock"

Issue #2055 Update (Edit) "drop privileges before creating zopectlsock"
 ** Security Related ** (Public)
 Status Pending, Zope/bug medium
To followup, visit:
  http://www.zope.org/Collectors/Zope/2055

==============================================================
= Edit - Entry #7 by tseaver on Dec 19, 2006 2:18 pm

 Changes: edited transcript, topic (ZServer => Zope), new comment

This is a bug related to zdaemon / zopectl, not ZServer.
________________________________________
= Comment - Entry #6 by joernclausen on May 22, 2006 3:30 pm

> We could recharacterize this issue as a request to have 'zopectl'
> honor the 'effective-user' setting (while still being overridable
> on the command line).  Would that suit your need?

That's fine with me. I simply didn't know about the '-u user' switch (at least not that it has a different meaning than effective-user). Mention it in the description of effective-user in zope.conf, and IMHO it's okay.
________________________________________
= Comment - Entry #5 by tseaver on May 17, 2006 12:29 pm

The original poster replied to me in mail:

  The NFS problem is not security related.

  Creating a file as root at a predictable place, with a
  predictable name, in a situation where the unwary user might not
  expect it (because he has told Zope to drop all privileges),
  that is IMHO the security problem.

  Hope that clarifies my request.

I looked into it, and can see the point.  However, the 'effective-user' setting in zope.conf governs the *child* process,
not the controller process (which creates the socket).

The controller can be run with dropped privileges, but that
requires a command-line argument, e.g.:

  # /path/to/instance/bin/zopectl -u unprivileged

We could recharacterize this issue as a request to have 'zopectl'
honor the 'effective-user' setting (while still being overridable
on the command line).  Would that suit your need?

Also, as a clarification:  in a properly configured Zope instance,
the 'var' subdirectory is owned by the "unprivileged" user,
and marked as unreadable / unwritable by other users. In this
case, there should be no expectation that any file created in
that directory is precious outside of Zope.

This scenario is unlike 'tempfile symlink attack', in which
any user might create a file (or symlink) and trick root
into overwriting it.
________________________________________
= Comment - Entry #4 by tseaver on May 16, 2006 11:43 am

I'm not sure I agree here:  the ownership of that socket conveys
the right to control the daemonized process.  If we *don't* drop
privileges before creating it, then only the root user can
use zopectl to control it (the effective user can still send
it signals however).
________________________________________
= Unrestrict_pending - Entry #3 by tseaver on May 16, 2006 11:40 am

Not exploitable, opening issue for general view.
________________________________________
= Edit - Entry #2 by tseaver on May 16, 2006 11:40 am

 Changes: new comment

This issue does not involve an expoitable hole, which is what "security related" is supposed to mean.
________________________________________
= Request - Entry #1 by Anonymous User on Mar 29, 2006 3:56 am

When starting as root, Zope should drop its privileges before creating var/zopectlsock. Otherwise this file is owned by root. In our current setup, var is NFS mounted, so the file cannot be created. More important: As the privileges are usually dropped for security reasons, this file should be created by the non-privileged user anyway.
==============================================================