Bill Landry wrote:

I change the aliases.db to be group writeable, and even tried setting the ownership to root:mailman, but "bin/check_perms" did not like that and set the permission back to mailman:mailman. The aliase* files now look like (with no bin/check_perms issues reported):

-rw-rw-r-- 1 mailman mailman 107000 Jun 6 08:59 aliases -rw-rw-r-- 1 mailman mailman 167936 Jun 6 08:59 aliases.db

but I am still seeing the same problem reported in the maillog:

Jun 6 10:52:07 lists postfix/local[20108]: warning: cannot find alias database owner for hash:/usr/local/mailman/data/aliases(0,34100)

What happens if you leave the ownership as root:mailman in spite of check_perms?

Have you followed the Postfix setup instructions at for example http://mailman.sourceforge.net/mailman-install/node12.html (mirrors at http://www.gnu.org/software/mailman/mailman-install/node12.html and http://www.list.org/mailman-install/node12.html

In any case, this appears to be a postfix configuration issue. A google search for "cannot find alias database owner" turns up two links to a postfix module alias.c, the relevant piece of which is:

/*
 * DELIVERY RIGHTS
 * 
 * What rights to use for |command and /file/name deliveries? The
 * command and file code will use default rights when the alias
 * database is owned by root, otherwise it will use the rights of
 * the alias database owner.
 */
if ((alias_uid = dict_owner(*cpp)) == 0) {
alias_pwd = 0;
RESET_USER_ATTR(usr_attr, state.level);
} else {
if ((alias_pwd = mypwuid(alias_uid)) == 0) {
    msg_warn("cannot find alias database owner for %s", *cpp);
    *statusp = defer_append(BOUNCE_FLAG_KEEP,
			    BOUNCE_ATTR(state.msg_attr),
			"cannot find alias database owner");
    return (YES);
}
SET_USER_ATTR(usr_attr, alias_pwd, state.level);
}

-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Bill Landry wrote:

----- Original Message ----- From: "Mark Sapiro" msapiro@value.net

...

What happens if you leave the ownership as root:mailman in spite of check_perms?

Then I get the following in the maillog:

Jun 6 12:22:45 lists postfix/local[20474]: 711426FE2C: to=curtistest@lists.siemensmedical.com, relay=local, delay=1, status=bounced (Command died with status 1: "/usr/local/mailman/mail/mailman post curtistest")

and I get back an undeliverable message.

And did that say anything about a group mismatch error? Or is there anything in Mailman's 'error' log?

If you're getting group mismatch errors, see FAQ article 6.16

Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py

...

Have you followed the Postfix setup instructions at for example http://mailman.sourceforge.net/mailman-install/node12.html (mirrors at http://www.gnu.org/software/mailman/mailman-install/node12.html and http://www.list.org/mailman-install/node12.html

Yes.

...

In any case, this appears to be a postfix configuration issue. A google search for "cannot find alias database owner" turns up two links to a postfix module alias.c, the relevant piece of which is:

/*
 * DELIVERY RIGHTS

Not sure what to do with this code snippet.

Nor I. I only mentioned it because the comment seems to indicate that if the aliases.db (and aliases) is owned by mailman, postfix has to be told something about what "rights" to give mailman.

If you have any further advice based on the "Command died with status 1" I receive when setting the aliases.db perms to root:mailman, please let me know. Otherwise, I will post this to the Postfix list to see what they have to say.

As above, I think setting the owner of the aliases to root allowed postfix to pipe the message to the mailman wrapper which then died. What usually causes this is the "group mismatch error".

-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

----- Original Message ----- From: "John Dennis" jdennis@redhat.com

On Mon, 2005-06-06 at 12:48 -0700, Mark Sapiro wrote:

...

And did that say anything about a group mismatch error? Or is there anything in Mailman's 'error' log?

If you're getting group mismatch errors, see FAQ article 6.16

FWIW, I don't think this problem will manifest itself as a mailman group mismatch error, but I could be wrong.

Thinking about this a bit more I suspect Bill may have modified the user/group on the alias file and/or modified the mailman account information while postfix was running, but did not restart postfix. I haven't looked at the postfix code but I wouldn't be surprised if postfix when it starts gets file information on all its input files referenced in main.cf and stores that information. If that information was altered while postfix was running it would likely get confused because it may be using id's that no longer exist.

John, I've tried to make sure that I either reload or restart Postfix and Mailman after each config or file permissions change. Thanks for the help guys, it is very much appreciated. I've posted the issue to the Postfix list, so if I can find a resolution there, I will post it back here. If you can think of anything else I should look at, please let me know.

Thanks again!

Bill

----- Original Message ----- From: "John Dennis" jdennis@redhat.com

On Mon, 2005-06-06 at 11:46 -0700, Mark Sapiro wrote:

...

Bill Landry wrote:

...

Jun 6 10:52:07 lists postfix/local[20108]: warning: cannot find alias database owner for hash:/usr/local/mailman/data/aliases(0,34100)

...

In any case, this appears to be a postfix configuration issue. A google search for "cannot find alias database owner" turns up two links to a postfix module alias.c, the relevant piece of which is:

I don't think this is a postfix configuration issue, but rather a problem with user lookup's. What the code in question is doing is getting the user id (uid) of the owner of of the alias file and then mapping it to an account. For some reason that's failing. On the machine that postfix is running on you should verify the mailman account exists. (what does the command "id mailman" return?).

id mailman uid=41(mailman) gid=41(mailman) groups=41(mailman)

Are you running postfix and mailman on the same machine.

Yes.

Do you have any of the files on an NFS mount?

No.

It seems very odd that ls -l prints out mailman as the owner but postfix can't perform the same lookup. Are you running a NSCD (Name Service Cache Daemon)?

No.

If so, maybe the cache isn't refreshed. Have you tried restarting postfix?

Yes, many times.

Is mailman in /etc/shadow on the machine postfix is running on?

grep mailman /etc/shadow mailman:!!:12327::::::

Bill

----- Original Message ----- From: "John Dennis" jdennis@redhat.com

On Mon, 2005-06-06 at 13:00 -0700, Bill Landry wrote:

O.K. the other things I suggested you check all seem fine.

...

...

Is mailman in /etc/shadow on the machine postfix is running on?

grep mailman /etc/shadow mailman:!!:12327::::::

Actually /etc/passwd maybe more relevant in this instance. If postfix does not have permission to read /etc/passwd it's look up is going to fail (a non-readable /etc/group may also provoke this). Recall that postfix typically does not run as root for very good reasons. What postfix runs as is configurable. You want to make sure whatever user postfix is running as has permission to read these /etc files. Also typically /etc/passwd and /etc/group are readable by everybody. The only other thing I can think of for you to check is to assure /etc/passwd and /etc/group are readable by the postfix process.

Short of that the only other things I can think of would be to strace (assuming you're on a system with strace, e.g. Linux) the postfix process and seeing where the failure occurs and/or to look at the postfix code that performs the lookup and see exactly what c lib functions it's calling and what triggers it to return a failure.

This appears to be the standard across all of my RedHat 9/Postfix and Fedora Core3/Postfix servers:

ls -l /etc/passwd -rw-r--r-- 1 root root 2172 Jun 6 09:16 /etc/passwd ls -l /etc/group -rw-r--r-- 1 root root 974 Jun 6 13:34 /etc/group

My other Postfix servers are function properly, and they all run as "mail_owner = postfix", including this particular Mailman server, so I am still a bit baffled by this one.

Bill

On Tue, 2005-06-07 at 02:42 -0700, Bill Landry wrote:

Doh, ended up being a chroot issue in master.cf. Thanks John, Mark, and Dan for the responses, and my apologies to the list for the noise...

Glad you got it fixed.

I'd like to take this opportunity to make a few comments about chroot jails, this is not directed at you or your choice to use them but rather as a general comment of interest to the wider community.

For what its worth I see this as a prime example of why I no longer recommend people run postfix (and other services) in a chroot jail. We stopped shipping postfix chrooted several years ago after observing the inordinate amount of problems it created for a marginal security win. Postfix is now often configured to interact with a host of other software components (SASL, TLS, SQL databases, LDAP directories, mailing list managers, spam filters, challenage/response authentcation methods, etc.) and as such its tenticles reach deep and wide. Trying to keep all these diverese elements in sync in a jail is a headache and a source of numerous problems often ascribed as bugs but which aren't. Even Wietse Venema the author of postfix no longer recommends the use of chroot jails although this was a design center of the original postfix security model. Chroot jails can be broken out of. Even without chroot jails postfix maintains a fairly robust security profile because of its design.

Finally, with the advent of SELinux (yes, postfix, mailman, and apache are under the control of SELinux on Red Hat systems) the value of a jail is greatly diminished in favor of the vastly more robust security model inherent in SELinux. In fact it might be a reasonable statement that SELinux is itself a system wide jail enforced at the kernel level for every process and every object (e.g. files, sockets, devices, etc.). It is a Mandatory Access Control (MAC) sytem which means it cannot be defeated and offers great granularity (and unforuntely its own set of new headaces as the wrinkles in the security policy are ironed out ;-)