[milters] Archive

Lists Index Date Thread Search

Article: 1160
From: Anthony Howe
Date: 2006-09-30 03:36:36 -0400
Subject: Re: milter-link issue

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support

Ken A wrote:
> Anthony Howe wrote:
>> Ken A wrote:
>>> Using milter-link version 0.2.13 / LibSnert 1.61
>>> I've noticed a issue where milter-link began ignoring it's whitelist 
>>> access db. Not sure what caused it, but a restart fixed it. I see there 
>> Check file permissions & ownership. When you restart the milter it 
>> starts as root, opens its .pid and the access.db, then changes ownership 
>> to milter:milter. Subsequent updates of access.db will be detected and 
>> reopened only if process as milter:milter can read access.db. The 
>> symptom you describe would indicate that access.db has permission and/or 
>> ownership problems.
> I use access-db=/etc/mail/milter-link-access.db in the command line and
> -rw-r--r--  1 root root  49152 Sep 28 15:49 milter-link-access.db

Its world readable which is fine, but otherwise it should be owned by 
milter:milter, then you could remove the world-readable permission.

> it's readable.
> Does milter link also require access to sendmail's access.db ?
> sendmail's access.db has other functions, so I like to keep the two 
> separate. Is this perhaps an issue?

You can specify a different access.db from that of sendmail, but the 
whole point of using the sendmail access.db is to a) avoid duplication 
of information and b) keep all the information centralised.

Another thing that can cause any of my milters to not reopen the 
access.db file depends on how you update the file. If you simply 
overwrite the access.db with:

	makemap hash access <access

my milters _will_ detect the update and reopen the access.db.

If you have a script or makefile that does a "create then move", like:

	makemap hash access.new <access
	mv access.new.db access.db

this will fail, because my milter maintain an open file descriptor to 
the old access.db so that they can use fstat(), instead of stat(), to 
detect a file update, which is faster and more efficient. fstat() will 
not see the file replacement. This is related the common unix idiom that 
a file is not deleted until the last file descriptor is closed.

Anthony C Howe          Skype: SirWumpus                    SnertSoft
+33 6 11 89 73 78         AIM: SirWumpus    Sendmail Milter Solutions
http://www.snert.com/     ICQ: 7116561

Lists Index Date Thread Search