From owner-freebsd-security Sun Jun 9 08:57:09 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA04040 for security-outgoing; Sun, 9 Jun 1996 08:57:09 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA04022 for ; Sun, 9 Jun 1996 08:57:05 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id LAA12444; Sun, 9 Jun 1996 11:56:05 -0400 (EDT) Date: Sun, 9 Jun 1996 11:56:10 -0400 (EDT) From: Brian Tao To: Ade Barkah cc: security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-Reply-To: <199606090954.DAA11025@hemi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Jun 1996, Ade Barkah wrote: > > But this is what started the thread, right ? With the current scheme > qpop 2.2 will not work with FreeBSD; at least not for new users (it > doesn't have enough permissions to set up the per-mailbox lock file.) There is the general case of wanting non-setuid programs vs. write-protected directories. The POP daemon case was one specific example of that. I already have enough files in /var/mail, so I've always used /var/mail/.tmp (yes, we have a user named tmp@io.org, *sigh*). It is world writeable, but I have a separate mail server that is secured from user logins, so it isn't a problem here. An alternative would be to modify your newuser procedure to touch and chown a .pop lock file for the user and configure your POP server not to remove those files when the user exits. From the qpopper 2.2 install notes: h) KEEP_TEMP_DROP - Keep the .user.pop file around. It can be used to determine when the last time a user has accessed their mail. [...] 3) When qpopper runs it moves your mailspool to a temporary location (.user.pop). The default location is in the mail spool directory. /tmp is an alternative but is consider to be a security risk and a system reboot will probably clear the temporary .user.pop files. For performance reasons a sysadmin who has many users (say 1000 or more) can create a separate spool directory for popper files. /usr/spool/poptemp could be a good choice. Permissions should the same as your mailspool as well as the same owner and group. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't"