From owner-freebsd-ports@FreeBSD.ORG Sat Apr 21 02:26:22 2007 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 376CD16A400 for ; Sat, 21 Apr 2007 02:26:22 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from mail.stovebolt.com (mail.stovebolt.com [66.221.101.249]) by mx1.freebsd.org (Postfix) with ESMTP id 06FDA13C44B for ; Sat, 21 Apr 2007 02:26:21 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from [192.168.2.102] (adsl-66-137-149-124.dsl.rcsntx.swbell.net [66.137.149.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.stovebolt.com (Postfix) with ESMTP id 26449114326; Fri, 20 Apr 2007 21:26:47 -0500 (CDT) Date: Fri, 20 Apr 2007 21:26:19 -0500 From: Paul Schmehl To: Jeffrey Goldberg Message-ID: <241A5B7DB4C2BB1A9FE54C99@paul-schmehls-powerbook59.local> In-Reply-To: References: <200704200842.48793.david@vizion2000.net> <94592079D5FE1208BC6F7D03@utd59514.utdallas.edu> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========B084E305AE1EF640966F==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, Jean Milanez Melo Subject: Re: Mailman GID problem X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 02:26:22 -0000 --==========B084E305AE1EF640966F========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On April 20, 2007 7:54:45 PM -0500 Jeffrey Goldberg=20 wrote: > > I think I'm beginning to understand where that "nobody" comes from and > why you are right about that. > > Here is an excerpt from the postfix aliases(5) > > In the absence of a user context, the local(8) daemon uses the > owner > rights of the :include: file or alias database. When those files > are > owned by the superuser, delivery is made with the rights specified > with > the default_privs configuration parameter. > > I had been looking at the first half of that (which I was already aware > of). So I thought that if the wrapper were compiled to only run as > "nobody" than the relevant alias files had to be owned by "nobody". I > wasn't, until looking this up, aware of what happens when the aliases > file is owned by root. > > In the postfix out of ports on FreeBSD, default_privs is set to = "nobody". > > So the first fix (modifying the owner of data/aliases{,.db}) is the > right way to go, but instead of making those files owned by "nobody" > (which does seem dangerous because than anything running as "nobody" > could change those file) they should be owned by root with mailman as > the group and permissions like 664. > Nobody is an unprivileged user. grep nobody /etc/passwd nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin So, using that account would *increase*, not decrease, security.=20 However.... > Let me just test that now... Yes. Mail delivery seems to work with > > [jeffrey@dobby /usr/local/mailman/data]$ ls -la . > total 78 > drwxrwsr-x 2 root mailman 1024 Apr 19 16:03 . > drwxrwsr-x 20 mailman mailman 512 Mar 30 13:57 .. > -rw-r----- 1 root mailman 41 Sep 11 2006 adm.pw > -rw-rw---- 1 root mailman 3523 Mar 31 16:10 aliases > -rw-rw-r-- 1 root mailman 16384 Mar 31 16:10 aliases.db > -rw-rw-r-- 1 root mailman 12288 Sep 13 2006 aliases.db.rpmsave > -rw-r----- 1 root mailman 41 Sep 11 2006 creator.pw > -rw-r--r-- 1 root mailman 10 Mar 30 13:57 last_mailman_version > -rw-rw---- 1 root mailman 4 Apr 17 14:34 master-qrunner.pid > -rw-r--r-- 1 root mailman 14114 Mar 30 13:57 sitelist.cfg > -rw-rw---- 1 root mailman 3334 Mar 31 16:10 virtual-mailman > -rw-rw-r-- 1 root mailman 16384 Mar 31 16:10 virtual-mailman.db > > I haven't yet tested list creation, but the permissions look fine to me. > All of the relevant files (as well as the data directory itself) are > writable by members of the mailman group. > > But I think I now see the problem > > $ ../bin/check_perms > /usr/local/mailman/data/aliases.db owned by root (must be owned by > mailman > /usr/local/mailman/data/virtual-mailman.db owned by root (must be owned > by mailman > Problems found: 2 > Re-run as mailman (or root) with -f flag to fix > > Somehow check_perms doesn't seem to know how postfix does things. If I > were to actually run > > check_perms -f > > it would break to ownership of the aliases file so that we would have > the mismatch between what the uid postfix gives the the wrapper > ("mailman") and what the wrapper demands ("nobody"). > Nope. I've been running mailman for years now, and it works perfectly=20 fine. The owner of the data directory is mailman, and the group is=20 mailman. ls -lsa /usr/local/mailman/data/ total 132 2 drwxrwsr-x 2 mailman mailman 512 Apr 7 19:47 . 2 drwxrwsr-x 20 mailman mailman 512 Nov 28 17:48 .. 48 -rw-r--r-- 1 mailman mailman 65536 Sep 6 2005 .db 2 -rw-r----- 1 mailman mailman 41 Sep 6 2005 adm.pw 6 -rw-r--r-- 1 root mailman 4383 Oct 14 2005 aliases 4 -rw-r----- 1 mailman mailman 3984 Sep 8 2005 aliases.bak 48 -rw-r----- 1 mailman mailman 49152 May 5 2006 aliases.db 0 -rw-rw-rw- 1 mailman mailman 0 Sep 9 2005=20 bounce-events-00446.pck 0 -rw-rw-rw- 1 mailman mailman 0 Sep 9 2005=20 bounce-events-00449.pck 0 -rw-rw-rw- 1 mailman mailman 0 Sep 9 2005=20 bounce-events-00467.pck 0 -rw-rw-rw- 1 mailman mailman 0 Jan 27 2006=20 bounce-events-00567.pck 0 -rw-rw-rw- 1 mailman mailman 0 Oct 13 2005=20 bounce-events-38840.pck 2 -rw-r----- 1 mailman mailman 41 Sep 6 2005 creator.pw 2 -rw-r--r-- 1 root mailman 10 Nov 28 17:48 = last_mailman_version 2 -rw-rw---- 1 mailman mailman 4 Apr 1 08:31 master-qrunner.pid 14 -rw-r--r-- 1 root mailman 14114 Nov 28 17:48 sitelist.cfg It is the *group* that matters to postfix, *not* the owner. Per the=20 pkg-message file: Mailman has been installed, but requires further configuration before use! You will have to configure both your MTA (mail server) and web server to integrate with Mailman. If the port's documentation has been installed, extensive post-installation instructions may be found in: %%DOCSDIR%%/FreeBSD-post-install-notes Note (1): If you use an alternate (non-Sendmail) MTA, you MUST be sure that the correct value of MAIL_GID was used when this port or package was built. Performing a "make options" in the Mailman port directory will list required values for various mail servers. Note that MAIL_GID is what matters. That is the *group* not the owner of=20 the files. Note also that the group only has read writes to the aliases=20 file, although it does have read/write access to the bounce-events files. > So maybe the problem is with check_perms and not with the port at all > (well the port would still need to get the aliases files owned by root). > There's nothing at all wrong with the check_perms script. > While setting the aliases files to be owned by "nobody" or by making the > wrapper want "mailman" instead of "nobody" would be work-arounds, both > of those lose out on the security achieved by having the aliases files > owned by root. > There's no increased benefit of having root own the aliases file. In=20 fact, while root owns the aliases db for postfix: ls -lsa /usr/local/etc/postfix/aliases* 4 -rw-r--r-- 1 root wheel 2923 Feb 11 22:11=20 /usr/local/etc/postfix/aliases 48 -rw-r--r-- 1 root wheel 49152 Feb 11 22:11=20 /usr/local/etc/postfix/aliases.db mailman owns the aliases db for mailman: ls -lsa /usr/local/mailman/data/aliases* 6 -rw-r--r-- 1 root mailman 4383 Oct 14 2005=20 /usr/local/mailman/data/aliases 4 -rw-r----- 1 mailman mailman 3984 Sep 8 2005=20 /usr/local/mailman/data/aliases.bak 48 -rw-r----- 1 mailman mailman 49152 May 5 2006=20 /usr/local/mailman/data/aliases.db And this is a working setup of mailman and postfix that's been running for = years. > Of course my two previous "understandings" of how things were supposed > to work were wrong. So please take my current analysis with a large > grain of salt. > Done. Paul Schmehl (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========B084E305AE1EF640966F==========--