Loading ...
Sorry, an error occurred while loading the content.

Understanding priviliges when delivering to external commands

Expand Messages
  • Andrew Beverley
    I ve been using the default_privs setting to control which user Postfix uses to deliver mail to external commands. However, I note from the manual that this
    Message 1 of 5 , Jun 4, 2012
    • 0 Attachment
      I've been using the default_privs setting to control which user Postfix
      uses to deliver mail to external commands. However, I note from the
      manual that this setting is only used "from an aliases file that is
      owned by root, or when delivery is done on behalf of root".

      I've come across instances when mail is still delivered to a command
      using the user "nobody" (such as when a mail is generated from the local
      server rather than delivered from an external source). Is there any way
      to change the user that is used to deliver *all* mail to external
      commands? If not, what is the recommended way of delivering to an
      external command and ensuring that the external command is always
      executed using the correct privileges?

      At the moment, the only way I can see to achieve this is to set the
      external command as executable by "nobody" and external files as
      writable by "nobody", but it doesn't seem right to do this in case other
      processes are utilising "nobody".

      Thoughts please?

      postconf -n as follows:

      alias_database = hash:/etc/postfix/aliases
      alias_maps = hash:/etc/postfix/aliases, regexp:/etc/postfix/aliases-regexp
      allow_min_user = yes
      command_time_limit = 5000
      config_directory = /etc/postfix
      default_privs = simple
      header_checks = regexp:/etc/postfix/header_checks
      home_mailbox = Maildir/
      html_directory = /usr/share/doc/postfix-2.3.3/html
      inet_interfaces = root.simplelists.com, localhost
      mailq_path = /usr/bin/mailq
      manpage_directory = /usr/share/man
      message_size_limit = 20480000
      milter_connect_macros = i b j _ {daemon_name} {if_name} {if_addr}
      milter_default_action = accept
      milter_mail_macros = {auth_author} {auth_type} {auth_authen}
      multi_instance_directories = /etc/postfix-trusted /etc/postfix-untrusted /etc/postfix-reqconf
      multi_instance_enable = yes
      multi_instance_wrapper = ${command_directory}/postmulti -p --
      mydestination = $myhostname, localhost.$mydomain, localhost, mx1.$mydomain, ns1.$mydomain, www.$mydomain, root.$mydomain, neptune.$mydomain, earth.$mydomain, pluto.$mydomain, saturn.$mydomain
      myhostname = earth.simplelists.com
      mynetworks = 89.16.184.168/29,89.16.176.81,217.160.183.50/32,127.0.0.1/32
      newaliases_path = /usr/bin/newaliases
      non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock
      parent_domain_matches_subdomains =
      queue_directory = /var/spool/postfix
      readme_directory = /usr/share/doc/postfix-2.3.3/README
      sample_directory = /etc/postfix
      sendmail_path = /usr/sbin/sendmail
      smtpd_authorized_verp_clients = $mynetworks
      smtpd_client_restrictions = reject_rbl_client zen.spamhaus.org
      smtpd_helo_required = yes
      smtpd_helo_restrictions = permit_mynetworks, check_recipient_access hash:/etc/postfix/access, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname
      smtpd_milters = unix:/var/run/clamav/milter.ctl unix:/var/spool/postfix/spamass/spamass.sock
      smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/access, reject_unknown_sender_domain, permit_mynetworks, reject_unauth_destination,reject_unauth_pipelining
      smtpd_restriction_classes = restrict_smtp_ip
      smtpd_sasl_local_domain = $myhostname
      transport_maps = hash:/etc/postfix/transport
      unknown_local_recipient_reject_code = 550
      virtual_alias_domains = proxy:mysql:/etc/postfix/mysql-virtual-domains.cf, /etc/postfix/virtual-domains
      virtual_alias_maps = hash:/etc/postfix/virtual, regexp:/etc/postfix/virtual-regexp, proxy:mysql:/etc/postfix/mysql-other-aliases.cf, proxy:mysql:/etc/postfix/mysql-multiple-domain-aliases.cf, proxy:mysql:/etc/postfix/mysql-global-aliases.cf, proxy:mysql:/etc/postfix/mysql-bounce-aliases.cf, proxy:mysql:/etc/postfix/mysql-majordomo-aliases.cf, proxy:mysql:/etc/postfix/mysql-account-aliases.cf
    • /dev/rob0
      ... Right. When an aliases or .forward file is owned by a different user, and mail is received for that user (or an alias in that file), that user is the one
      Message 2 of 5 , Jun 4, 2012
      • 0 Attachment
        On Mon, Jun 04, 2012 at 10:38:02AM +0100, Andrew Beverley wrote:
        > I've been using the default_privs setting to control which user
        > Postfix uses to deliver mail to external commands. However, I note
        > from the manual that this setting is only used "from an aliases
        > file that is owned by root, or when delivery is done on behalf of
        > root".

        Right. When an aliases or .forward file is owned by a different user,
        and mail is received for that user (or an alias in that file), that
        user is the one running any command specified.

        > I've come across instances when mail is still delivered to a
        > command using the user "nobody" (such as when a mail is generated
        > from the local server rather than delivered from an external
        > source).

        You forgot to include logs and evidence (file ownership and modes)
        regarding these instances, so it is not possible to comment other
        than a WAG. My WAG here is that multiple instances are involved:
        local processes are invoking sendmail(1) in another instance.

        > Is there any way to change the user that is used to deliver *all*
        > mail to external commands?

        No, that would not make sense for the local(8) delivery agent,
        wherein the recipient is the one running any command. Perhaps you
        would be interested in pipe(8)? You have not said what the problem
        and ultimate goal is.

        > If not, what is the recommended way of delivering to an
        > external command and ensuring that the external command is always
        > executed using the correct privileges?

        Execution of external commands is not random. Again it's hard to say
        anything more, not knowing what is actually happening.

        > At the moment, the only way I can see to achieve this is to set the
        > external command as executable by "nobody" and external files as
        > writable by "nobody", but it doesn't seem right to do this in case
        > other processes are utilising "nobody".
        >
        > Thoughts please?
        >
        > postconf -n as follows:

        > alias_maps = hash:/etc/postfix/aliases,
        > regexp:/etc/postfix/aliases-regexp

        Who owns these? Do they contain any of the affected aliases?

        > html_directory = /usr/share/doc/postfix-2.3.3/html

        Hmmm, 2.3.3 is very old, and did not have support for this:

        > multi_instance_directories = /etc/postfix-trusted
        > /etc/postfix-untrusted /etc/postfix-reqconf
        > multi_instance_enable = yes
        > multi_instance_wrapper = ${command_directory}/postmulti -p --

        You are running multiple instances on at least Postfix 2.6. Have you
        distinguished the logging of each instance? Do you know for a fact
        that none of these other instances is doing what you see?

        > transport_maps = hash:/etc/postfix/transport

        What is this doing? Is it sending anything to a pipe(8) transport?
        --
        http://rob0.nodns4.us/ -- system administration and consulting
        Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
      • Andrew Beverley
        ... Thanks for the reply. You were correct: another Postfix instance was indeed being used that didn t have default_privs set (because I thought it was only
        Message 3 of 5 , Jun 30, 2012
        • 0 Attachment
          On Mon, 2012-06-04 at 15:47 -0500, /dev/rob0 wrote:
          > > I've come across instances when mail is still delivered to a
          > > command using the user "nobody" (such as when a mail is generated
          > > from the local server rather than delivered from an external
          > > source).
          >
          > You forgot to include logs and evidence (file ownership and modes)
          > regarding these instances, so it is not possible to comment other
          > than a WAG. My WAG here is that multiple instances are involved:
          > local processes are invoking sendmail(1) in another instance.

          Thanks for the reply. You were correct: another Postfix instance was
          indeed being used that didn't have default_privs set (because I thought
          it was only being used to deliver mail externally). In certain
          circumstances, it was delivering mail locally on behalf of the main
          Postfix instance, and was thus defaulting to the "nobody" user.

          > > Is there any way to change the user that is used to deliver *all*
          > > mail to external commands?
          >
          > No, that would not make sense for the local(8) delivery agent,
          > wherein the recipient is the one running any command. Perhaps you
          > would be interested in pipe(8)?

          Actually, that looks like a better solution. Thank you.

          > You have not said what the problem
          > and ultimate goal is.

          > > html_directory = /usr/share/doc/postfix-2.3.3/html
          >
          > Hmmm, 2.3.3 is very old, and did not have support for this:

          Well spotted. I should have said: this is Postfix 2.7.1. That's a
          hangover from the original installation.

          Thanks again for the reply.

          Andy
        • Reindl Harald
          ... make a bugreport to your distribution! as example fedora ALWAYS updates this paths while update postfix
          Message 4 of 5 , Jun 30, 2012
          • 0 Attachment
            Am 30.06.2012 22:41, schrieb Andrew Beverley:
            >>> html_directory = /usr/share/doc/postfix-2.3.3/html
            >>
            >> Hmmm, 2.3.3 is very old, and did not have support for this:
            >
            > Well spotted. I should have said: this is Postfix 2.7.1. That's a
            > hangover from the original installation.

            make a bugreport to your distribution!
            as example fedora ALWAYS updates this paths while update postfix
          • Andrew Beverley
            ... Good idea... ... ... However, I ve just checked a recent fresh distro install (Debian) and it looks like it s already fixed. The documentation is now in
            Message 5 of 5 , Jun 30, 2012
            • 0 Attachment
              On Sat, 2012-06-30 at 22:53 +0200, Reindl Harald wrote:
              > Am 30.06.2012 22:41, schrieb Andrew Beverley:
              > >>> html_directory = /usr/share/doc/postfix-2.3.3/html
              > >>
              > >> Hmmm, 2.3.3 is very old, and did not have support for this:
              > >
              > > Well spotted. I should have said: this is Postfix 2.7.1. That's a
              > > hangover from the original installation.
              >
              > make a bugreport to your distribution!

              Good idea...

              > as example fedora ALWAYS updates this paths while update postfix

              ... However, I've just checked a recent fresh distro install (Debian)
              and it looks like it's already fixed. The documentation is now
              in /usr/share/doc/postfix and referenced correctly.

              Andy
            Your message has been successfully submitted and would be delivered to recipients shortly.