Wietse Venema wrote:
>
> Michael Tokarev:
> > Umm... Nope. Transport map entries aren't stored in queued messages,
> > but qmgr will look into transport_map when it will process the message.
> > So -- no, qmgr will pick up NEW transport map entry. Note however that
> > in case transport map change, qmgr will restart.
>
> Nope, transport maps are queries by the trivial-rewrite daemon.

Too much details for this issue but yes, I was incorrect too...
(I just wanted to point out that NEW transport entries will be
used).

And the fact that it's another process who queries transport maps,
and not qmgr, is "good by itself" -- so qmgr will not loose it's
in-memory state on transport map change. (not to say about virtual
maps etc).

> > Wow, interesting point: qmgr can benefit from having "self-reloading"
> > maps, i.e. for some map types like e.g. berkeley db3, there is no need
> > to reload it after a modification. Also, for non-chrooted process, it
> > can just reopen a map after a change -- for qmgr on large sites it may
> > be very useful. A time for "map reload jumbo patch"? ;)
>
> What about having given up root privileges after opening a map?

A side question. Why *all* maps are opened read-write in postfix, even
for query only? Possible locking problems on some systems? Note that
this can lead to security issues: alias_map can be opened by smtpd
(for local_recipient_maps), and in case it will be compromised, an
intruder will be able to *modify* aliases -- an this file is security
sensitive (ability to run "wrong command") -- this can be done even if
smtpd is chrooted.

But yes anyway, you're right (modulo this particular problem can be
"worked around" - not worth an effort imho).

> What about client-side caching?

I noticied this too.

> Wietse

Regards,
 Michael.
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]