Victor Duchovni:
> On Tue, Oct 13, 2009 at 01:05:18PM -0400, Wietse Venema wrote:
> 
> > Zhang Huangbin:
> > > Hi, all.
> > > 
> > > smtpd_sender_login_maps is missing in proxy_read_maps, is it a good  
> > > idea to add it by default? so that we can use proxymap(8) in  
> > > smtpd_sender_login_maps (with default proxy_read_maps).
> > 
> > I see no problem with doing this.
> 
> Currently proxy_read_maps includes the various (non security sensitive)
> "rewriting" related tables, and not others:
> 
>     #define DEF_PROXY_READ_MAPS     "$" VAR_LOCAL_RCPT_MAPS \
>                                   " $" VAR_MYDEST \
>                                   " $" VAR_VIRT_ALIAS_MAPS \
>                                   " $" VAR_VIRT_ALIAS_DOMS \
>                                   " $" VAR_VIRT_MAILBOX_MAPS \
>                                   " $" VAR_VIRT_MAILBOX_DOMS \
>                                   " $" VAR_RELAY_RCPT_MAPS \
>                                   " $" VAR_RELAY_DOMAINS \
>                                   " $" VAR_CANONICAL_MAPS \
>                                   " $" VAR_SEND_CANON_MAPS \
>                                   " $" VAR_RCPT_CANON_MAPS \
>                                   " $" VAR_RELOCATED_MAPS \
>                                   " $" VAR_TRANSPORT_MAPS \
>                                   " $" VAR_MYNETWORKS \
>                                   " $" VAR_SEND_BCC_MAPS \
>                                   " $" VAR_RCPT_BCC_MAPS \
>                                   " $" VAR_SMTP_GENERIC_MAPS \
>                                   " $" VAR_LMTP_GENERIC_MAPS
> 
> How comprehensive should the default list be?
> If smtpd_sender_login_maps is included, what else should be added?
>
>     address_verify_sender_dependent_relayhost_maps 
>     address_verify_transport_maps 
>     fallback_transport_maps 
>     lmtp_discard_lhlo_keyword_address_maps 
>     lmtp_pix_workaround_maps 
>     lmtp_sasl_password_maps 
>     lmtp_tls_policy_maps 
>     mailbox_transport_maps 
>     rbl_reply_maps 
>     sender_dependent_relayhost_maps 
>     smtp_discard_ehlo_keyword_address_maps 
>     smtp_pix_workaround_maps 
>     smtp_sasl_password_maps 
>     smtp_tls_policy_maps 
>     smtpd_discard_ehlo_keyword_address_maps 
>     smtpd_sender_login_maps 
> 
> Perhaps, more, the above are just the candidate parameters not listed
> whose names end in "_maps". There are at least also:
> 
>       lmtp_tls_per_site
>       smtp_tls_per_site
>       relay_clientcerts

A little background may be in order.

Postfix has table-driven mechanisms (some security-sensitive such
as alias_maps or virtual_uid_maps) and table lookup mechanisms
(some unsuitable for security-sensitive features, such as proxy:
or tcp:  maps).

The purpose of proxy_read maps is to access maps with "delayed
open" semantics (such as passwd or group) that would break when
used in chrooted daemons, and to reduce the number of handles
for "expensive" maps (such as *SQL or LDAP).

With proxy_write_maps the primary purpose is "single updater"
semantics (allowing read/write access without need for locks,
because the proxywrite server *is* the lock).

As of several years the security-sensitive table-driven mechanisms
won't allow lookups from proxy: or tcp: maps, so we don't have to
worry about that.  

So the main purpose of the proxy_read_maps list is damage control:
to avoid read access to the entire file system by a compromised
chrooted process. We also may may not want to list maps with
passwords here, but it is not the end of the world if we do.

In the case of proxy_write_maps it may also be desirable to limit
the list for damage-control purposes, and list only maps where it
is OK to accept updates from arbitrary Postfix daemon processes.

        Wietse

Reply via email to