From owner-freebsd-hackers  Fri Jun  7 05:39:57 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id FAA11816
          for hackers-outgoing; Fri, 7 Jun 1996 05:39:57 -0700 (PDT)
Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA11810;
          Fri, 7 Jun 1996 05:39:54 -0700 (PDT)
Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id FAA19708; Fri, 7 Jun 1996 05:39:23 -0700 (PDT)
Message-Id: <199606071239.FAA19708@precipice.shockwave.com>
To: security@freebsd.org
cc: committer@freebsd.org, core@freebsd.org, hackers@freebsd.org
Subject: FreeBSD's /var/mail permissions
Date: Fri, 07 Jun 1996 05:39:22 -0700
From: Paul Traina <pst@shockwave.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

General problem:
    Currently, /var/mail is set 0755 and mail.local is setuid root.
    Any program which needs to *create* a new file in /var/mail must
    be setuid root.  Any program which wishes to manipulate a user mail
    file needs no special permissions (other than user permissions).

    I consider this a generic bug, even though there's a specific
    reason motivating me to change it.

Specific problem:
    Previous versions of the popper port created a temporary file
    ".pop.username" in /var/mail as root, and then chowned the file
    over to the user.  This was changed to avoid a potential race
    condition.  The file creation is now done at user level.

    When I discussed this with the author of popper, he was adamant
    that /var/mail should be 1755 (ala 4.3BSD) or 775 with a group
    of mail (ala USG...barf).

    If popper were the only problem, I'd consider chosing a
    different directory for this temporary file to be created, such
    as /var/tmp.  This leads to a new set of problems and I consider
    it less secure than maintaining the file in /var/mail as we have
    always done.

Proposed solution:
    I'm considering creating group "mail" and going the setgid route,
    so that a program which creates files in /var/mail can be simply
    setgid mail.

    This is a well understood mail directory protection mechanism
    and employs the "principle of least privilege."

Impact:
    Programs that expect the current semantics will still work just
    fine (we wouldn't need to change elm or mail.local).  All we
    are doing is allowing setgid mail delivery programs create
    access to /var/mail.

Comments?

I hate changing permissions on such a vital hunk of FreeBSD without
discussion.  Please TRIM THE CC LINE and keep all discussion in
security@freebsd.org as opposed to the other lists.

Paul