Milter-greylist

The generic startup script found here:

http://milter-greylist.wikidot.com/linux-generic-startup-script

Did not work for me. With this script, the milter-greylist.sock socket file is owned by root.

The line that says:

daemon /usr/local/bin/milter-greylist -u $user $OPTIONS

Should be changed to:

daemon --user=$user /usr/local/bin/milter-greylist $OPTIONS

At least on Centos. This then correctly creates the socket file owned by the user specified in the script.

compconsultant <Compconsultant@...> wrote:

> The line that says:
> daemon /usr/local/bin/milter-greylist -u $user $OPTIONS
> 
> Should be changed to:
> daemon --user=$user /usr/local/bin/milter-greylist $OPTIONS

SInce I do not run any Linux installation, I cannot check this change
does not break on other systems. Someone can confirm this is okay on a
non-CentOS Linux distribution?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

On Fri, Jul 15, 2011 at 08:22:57AM +0200, manu@... wrote:
> compconsultant <Compconsultant@...> wrote:
> 
> > The line that says:
> > daemon /usr/local/bin/milter-greylist -u $user $OPTIONS
> > 
> > Should be changed to:
> > daemon --user=$user /usr/local/bin/milter-greylist $OPTIONS
> 
> SInce I do not run any Linux installation, I cannot check this change
> does not break on other systems. Someone can confirm this is okay on a
> non-CentOS Linux distribution?

At least for Redhat based systems (Fedora, CentOS, RHEL) this should be
ok. I'm not sure if the daemon function (a shell function from the RC
environment) is generally available for different distribution.
Therefore "daemon" is not that "generic" someone might expect. For a
generic script a special "functionality" should be placed better into
the application (-u from milter-greylist) instead to rely on --user for
every "daemon"-function implemention ...


Johann E. K.

Johann Klasek <johann@...> wrote:

> At least for Redhat based systems (Fedora, CentOS, RHEL) this should be
> ok. I'm not sure if the daemon function (a shell function from the RC
> environment) is generally available for different distribution.
> Therefore "daemon" is not that "generic" someone might expect. For a
> generic script a special "functionality" should be placed better into
> the application (-u from milter-greylist) instead to rely on --user for
> every "daemon"-function implemention ...

milter-greylist already has a -u. Perhaps there woule be merit de
refactor the script and dump the call to daemon?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

On Sat, Jul 30, 2011 at 06:54:10PM +0200, manu@... wrote:
> Johann Klasek <johann@...> wrote:
> 
> > At least for Redhat based systems (Fedora, CentOS, RHEL) this should be
> > ok. I'm not sure if the daemon function (a shell function from the RC
> > environment) is generally available for different distribution.
> > Therefore "daemon" is not that "generic" someone might expect. For a
> > generic script a special "functionality" should be placed better into
> > the application (-u from milter-greylist) instead to rely on --user for
> > every "daemon"-function implemention ...
> 
> milter-greylist already has a -u. Perhaps there woule be merit de
> refactor the script and dump the call to daemon?

Because of this option I would recommend not to use the "daemon" variant, we
can not rely on its portability (especially in context for "generic linux").
At the moment I have no idea of a situation where "daemon --user"
has any advantage over "milter-greylist -u" ...

Johann E.K.

--- In milter-greylist@yahoogroups.com, Johann Klasek <johann@...> wrote:

> Because of this option I would recommend not to use the "daemon" variant, we
> can not rely on its portability (especially in context for "generic linux").
> At the moment I have no idea of a situation where "daemon --user"
> has any advantage over "milter-greylist -u" ...

Ok, so, here's the advantage. If you set the user to something other than root, it errors out. That's why I added the daemon.

What SEEMS to happen using the original startup script on Centos is the files (such as the socket file) are built as root, THEN, the user changed to the correct user (in my case postfix), meaning, postfix cannot write to the files. Perhaps this is a bug in milter-greylist.

When run with daemon, the program is started as that user and this the files all have the correct owner. So, that's why I made this change.

On Thu, Aug 04, 2011 at 10:13:53PM -0000, compconsultant wrote:
> --- In milter-greylist@yahoogroups.com, Johann Klasek <johann@...> wrote:
> 
> > Because of this option I would recommend not to use the "daemon" variant, we
> > can not rely on its portability (especially in context for "generic linux").
> > At the moment I have no idea of a situation where "daemon --user"
> > has any advantage over "milter-greylist -u" ...
> 
> Ok, so, here's the advantage. If you set the user to something other than root, it errors out. That's why I added the daemon.
> 
> What SEEMS to happen using the original startup script on Centos is the files (such as the socket file) are built as root, THEN, the user changed to the correct user (in my case postfix), meaning, postfix cannot write to the files. Perhaps this is a bug in milter-greylist.
> 
> When run with daemon, the program is started as that user and this the files all have the correct owner. So, that's why I made this change.

I see, that's why I probably switched to "daemon --user" on my Fedora
installation by myself ;)

In theory, the problem could be solved by setting the socket group und
socket permission in that way postfix is able to access the socket with
its group permission.
The socket permission is only changeable by means of the configuration file.
I agree, its not straight forward. The milter-greylist code should be better fixed
to set the ownership of the socket object to the appropriate user. Maybe not
necessary, but for consistency the PID file should be handled similar.


Johann E. K.

"compconsultant"
<Compconsultant-y+1K9gjoRMQAvxtiuMwx3w@...> writes:

> What SEEMS to happen using the original startup script on Centos is
> the files (such as the socket file) are built as root, THEN, the user
> changed to the correct user (in my case postfix), meaning, postfix
> cannot write to the files. Perhaps this is a bug in milter-greylist.

That's proper behavior.  Daemons usually delay dropping of permissions
until privileged operations have been finished.  Such privileged operations
are for example:

* creating pid file under /var/run (which is writable by root only)

* binding to ports < 1024

Both operations are done resp. are very likely to be done by milter-greylist
so that dropping the uid within the daemon is the right choice.

For your postfix problem I suggest to:

* use TCP for the milter socket, or

* place the unix socket into a protected directory which can be read by
  the postfix user/group and set a umask of 007 or 000 (this is already
  supported by milter-greylist's socket mode option).


Enrico

--- In milter-greylist@yahoogroups.com, Enrico Scholz <enrico.scholz@...> wrote:
>
> * use TCP for the milter socket, or
> 
> * place the unix socket into a protected directory which can be read by
>   the postfix user/group and set a umask of 007 or 000 (this is already
>   supported by milter-greylist's socket mode option).
> 

Don't want to use TCP, BUT, I do see the option, now, I guess I was looking at an older man page online and missed that. Thanks!