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

virtual permissions and virtual_gid_maps problems

Expand Messages
  • Dan
    On freebsd 8.0: standard install from ports collection: 1) virtual_gid_maps problems #GID does not appear to be working virtual_gid_maps =
    Message 1 of 19 , Nov 30, 2010
    • 0 Attachment
      On freebsd 8.0: standard install from ports collection:

      1) virtual_gid_maps problems
      #GID does not appear to be working
      virtual_gid_maps = mysql:$config_directory/mysql_gids.cf
      #virtual_gid_maps = static:2001


      Postfix creates new directories/mail with gid of postfix user only,
      completely ignoring virtual_gid_maps. I have tested both static and mysql
      configurations, same result.

      2) Postfix is not changing to root then chown'ing directories to
      appropriate virtual_uid_maps. Please see proftpd code as how they
      accomplish this. Problem is when you add a new "maildir" to mysql table
      that has not existed before, postfix will change euid to the uid of
      virtual_uid_maps, then attempt to create directories, which forces sys
      admin to make the virtual_base directory mode 777 as it constantly needs
      to create directories with new UIDs within there, so just doing a euid
      change to uid of virtual_uid_maps is not enough to do the initial create
      of first directory.

      Obviously a solution to this is for enduser to create the first directory
      ahead of time, but this should really be done server side.


      Dan.
    • Brian Evans - Postfix List
      ... Instead of quoting sections of main.cf, please check postconf -n and post that instead. This avoids problems of what Postfix is actually using versus
      Message 2 of 19 , Nov 30, 2010
      • 0 Attachment
        On 11/30/2010 11:49 AM, Dan wrote:
        >
        > On freebsd 8.0: standard install from ports collection:
        >
        > 1) virtual_gid_maps problems #GID does not appear to be working
        > virtual_gid_maps = mysql:$config_directory/mysql_gids.cf
        > #virtual_gid_maps = static:2001
        >
        Instead of quoting sections of main.cf, please check 'postconf -n' and
        post that instead.
        This avoids problems of what Postfix is actually using versus what you
        claim is right.

        >
        > Postfix creates new directories/mail with gid of postfix user only,
        > completely ignoring virtual_gid_maps. I have tested both static and
        > mysql configurations, same result.
        >
        > 2) Postfix is not changing to root then chown'ing directories to
        > appropriate virtual_uid_maps. Please see proftpd code as how they
        > accomplish this. Problem is when you add a new "maildir" to mysql
        > table that has not existed before, postfix will change euid to the uid of
        > virtual_uid_maps, then attempt to create directories, which forces sys
        > admin to make the virtual_base directory mode 777 as it constantly
        > needs to create directories with new UIDs within there, so just doing
        > a euid change to uid of virtual_uid_maps is not enough to do the
        > initial create of first directory.
        >
        > Obviously a solution to this is for enduser to create the first
        > directory ahead of time, but this should really be done server side.
        >
        >
        > Dan.
        >
      • Victor Duchovni
        ... Show evidence from your logs that mail is delivered via the virtual(8) agent and not by other means (dovecot LDA, Courier maildrop, ...). -- Viktor.
        Message 3 of 19 , Nov 30, 2010
        • 0 Attachment
          On Tue, Nov 30, 2010 at 10:49:39AM -0600, Dan wrote:

          >
          > On freebsd 8.0: standard install from ports collection:
          >
          > 1) virtual_gid_maps problems #GID does not appear to be working
          > virtual_gid_maps = mysql:$config_directory/mysql_gids.cf
          > #virtual_gid_maps = static:2001
          >
          >
          > Postfix creates new directories/mail with gid of postfix user only,
          > completely ignoring virtual_gid_maps. I have tested both static and mysql
          > configurations, same result.

          Show evidence from your logs that mail is delivered via the virtual(8)
          agent and not by other means (dovecot LDA, Courier maildrop, ...).

          --
          Viktor.
        • Dan
          As you request: postfix -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases config_directory = /usr/local/etc/postfix debug_peer_level = 2
          Message 4 of 19 , Nov 30, 2010
          • 0 Attachment
            As you request:

            postfix -n

            alias_database = hash:/etc/aliases
            alias_maps = hash:/etc/aliases
            config_directory = /usr/local/etc/postfix
            debug_peer_level = 2
            header_checks = regexp:$config_directory/header_checks
            home_mailbox = Maildir/
            html_directory = /usr/local/share/doc/postfix
            inet_interfaces = all
            inet_protocols = ipv4, ipv6
            local_recipient_maps = proxy:unix:passwd.byname $alias_maps
            mailq_path = /usr/local/bin/mailq
            manpage_directory = /usr/local/man
            mydestination = sunsaturn.com sunsaturn.sunsaturn.com localhost test.com
            mydomain = test.com
            myhostname = test.com
            mynetworks = $config_directory/mynetworks
            mynetworks_style = host
            myorigin = $myhostname
            newaliases_path = /usr/local/bin/newaliases
            non_smtpd_milters = inet:localhost:10026
            readme_directory = /usr/local/share/doc/postfix
            relay_domains = permit_sasl_authenticated, permit_mynetworks
            sample_directory = /usr/local/etc/postfix
            sender_dependent_default_transport_maps = mysql:$config_directory/mysql_outgoing.cf
            sendmail_path = /usr/local/sbin/sendmail
            setgid_group = maildrop
            smtpd_banner = $myhostname ESMTP
            smtpd_milters = inet:localhost:10026
            smtpd_recipient_restrictions = check_sender_access hash:$config_directory/badmailfrom,permit_mynetworks,permit_sasl_authenticated,reject_non_fqdn_hostname,reject_non_fqdn_sender,reject_non_fqdn_recipient,reject_unauth_destination,reject_unauth_pipelining,reject_invalid_hostname,reject_rbl_client bl.spamcop.net,reject_rbl_client zen.spamhaus.org,reject_rbl_client cbl.abuseat.org,reject_rbl_client psbl.surriel.com
            unknown_local_recipient_reject_code = 550
            virtual_alias_maps = mysql:$config_directory/mysql_aliases.cf
            virtual_gid_maps = mysql:$config_directory/mysql_gids.cf
            virtual_mailbox_base = /website/vuser
            virtual_mailbox_domains = mysql:$config_directory/mysql_domains.cf
            virtual_mailbox_limit = 51200000
            virtual_mailbox_maps = mysql:$config_directory/mysql_mailbox.cf
            virtual_minimum_uid = 2002
            virtual_uid_maps = mysql:$config_directory/mysql_uids.cf

            Mysql relevant table entries:

            email domain maildir
            test2@... test2.com test2.com/test2/Maildir/

            uid gid
            2003 2001

            Great lets start with completely empty /website/vuser:
            sunsaturn:~# rm -rf /website/vuser/*
            sunsaturn:~# ls -al /website/vuser/
            total 4K
            drwxrwxrwx 2 postfix postfix 512 Nov 30 19:21 .
            drwxr-xr-x 44 517 wheel 1024 Nov 30 04:10 ..
            sunsaturn:~# chmod 755 /website/vuser; chown postfix /website/vuser
            sunsaturn:~# ls -ald /website/vuser/
            drwxr-xr-x 2 postfix postfix 512 Nov 30 19:21 /website/vuser/
            sunsaturn:~#

            Now lets see the permissions problem:
            sunsaturn:~# echo test| mail test2@...
            sunsaturn:~# tail -10 /var/log/maillog
            Nov 30 19:22:52 sunsaturn postfix/pickup[21923]: 3EA8C119C56: uid=0
            from=<root>
            Nov 30 19:22:52 sunsaturn postfix/cleanup[23168]: 3EA8C119C56:
            message-id=<20101201012252.3EA8C119C56@...>
            Nov 30 19:22:52 sunsaturn dkim-filter[77781]: 3EA8C119C56 ADSP query:
            missing parameter(s) in policy data
            Nov 30 19:22:52 sunsaturn dkim-filter[77781]: 3EA8C119C56: no signature
            data
            Nov 30 19:22:52 sunsaturn postfix/qmgr[10416]: 3EA8C119C56:
            from=<root@...>, size=299, nrcpt=1 (queue active)
            Nov 30 19:22:52 sunsaturn postfix/virtual[23170]: warning: maildir access
            problem for UID/GID=2003/2001: create maildir file
            /website/vuser/test2.com/test2/Maildir/tmp/1291166572.P23170.sunsaturn.com:
            Permission denied
            Nov 30 19:22:52 sunsaturn postfix/virtual[23170]: warning: perhaps you
            need to create the maildirs in advance
            Nov 30 19:22:52 sunsaturn postfix/virtual[23170]: 3EA8C119C56:
            to=<test2@...>, relay=virtual, delay=0.07, delays=0.03/0.02/0/0.02,
            dsn=4.2.0, status=deferred (maildir delivery failed: create maildir file
            /website/vuser/test2.com/test2/Maildir/tmp/1291166572.P23170.sunsaturn.com:
            Permission denied)
            sunsaturn:~#

            Here we see problem for creating first directory under /website/vuser

            Now lets chmod 777 /website/vuser so that it can create directories under
            UID/GID=2003/2001 as it wants but in fact see that gid never is 2001.
            Gid 2001 under my system is vuser:
            sunsaturn:~# grep 2001 /etc/group
            vuser:*:2001:
            sunsaturn:~# chmod 777 /website/vuser; cd /website/vuser
            sunsaturn:/website/vuser# echo test| mail test2@...

            How from logs we can see it actually gets delivered:
            Nov 30 19:28:03 sunsaturn postfix/qmgr[10416]: DC276119C60:
            from=<root@...>, size=299, nrcpt=1 (queue active)
            Nov 30 19:28:03 sunsaturn postfix/virtual[23237]: DC276119C60:
            to=<test2@...>, relay=virtual, delay=0.01, delays=0.01/0/0/0,
            dsn=2.0.0, status=sent (delivered to maildir)
            Nov 30 19:28:03 sunsaturn postfix/qmgr[10416]: DC276119C60: removed
            Nov 30 19:29:03 sunsaturn postfix/qmgr[10416]: 3EA8C119C56:
            from=<root@...>, size=299, nrcpt=1 (queue active)
            Nov 30 19:29:03 sunsaturn postfix/virtual[23237]: 3EA8C119C56:
            to=<test2@...>, relay=virtual, delay=372, delays=372/0/0/0,
            dsn=2.0.0, status=sent (delivered to maildir)
            Nov 30 19:29:03 sunsaturn postfix/qmgr[10416]: 3EA8C119C56: removed

            So lets check file structure:

            sunsaturn:/website/vuser# ls -al
            total 6K
            drwxrwxrwx 3 postfix postfix 512 Nov 30 19:28 .
            drwxr-xr-x 44 517 wheel 1024 Nov 30 04:10 ..
            drwx------ 3 2003 postfix 512 Nov 30 19:28 test2.com
            sunsaturn:/website/vuser# ls
            test2.com
            sunsaturn:/website/vuser# find test2.com|xargs ls -al
            -rw------- 1 2003 postfix 347 Nov 30 19:28
            test2.com/test2/Maildir/new/1291166883.V59Ib97008M906598.sunsaturn.com
            -rw------- 1 2003 postfix 347 Nov 30 19:29
            test2.com/test2/Maildir/new/1291166943.V59Ib97001M911353.sunsaturn.com

            test2.com:
            total 6
            drwx------ 3 2003 postfix 512 Nov 30 19:28 .
            drwxrwxrwx 3 postfix postfix 512 Nov 30 19:28 ..
            drwx------ 3 2003 postfix 512 Nov 30 19:28 test2

            test2.com/test2:
            total 6
            drwx------ 3 2003 postfix 512 Nov 30 19:28 .
            drwx------ 3 2003 postfix 512 Nov 30 19:28 ..
            drwx------ 5 2003 postfix 512 Nov 30 19:28 Maildir

            test2.com/test2/Maildir:
            total 10
            drwx------ 5 2003 postfix 512 Nov 30 19:28 .
            drwx------ 3 2003 postfix 512 Nov 30 19:28 ..
            drwx------ 2 2003 postfix 512 Nov 30 19:28 cur
            drwx------ 2 2003 postfix 512 Nov 30 19:29 new
            drwx------ 2 2003 postfix 512 Nov 30 19:29 tmp

            test2.com/test2/Maildir/cur:
            total 4
            drwx------ 2 2003 postfix 512 Nov 30 19:28 .
            drwx------ 5 2003 postfix 512 Nov 30 19:28 ..

            test2.com/test2/Maildir/new:
            total 8
            drwx------ 2 2003 postfix 512 Nov 30 19:29 .
            drwx------ 5 2003 postfix 512 Nov 30 19:28 ..
            -rw------- 1 2003 postfix 347 Nov 30 19:28
            1291166883.V59Ib97008M906598.sunsaturn.com
            -rw------- 1 2003 postfix 347 Nov 30 19:29
            1291166943.V59Ib97001M911353.sunsaturn.com

            test2.com/test2/Maildir/tmp:
            total 4
            drwx------ 2 2003 postfix 512 Nov 30 19:29 .
            drwx------ 5 2003 postfix 512 Nov 30 19:28 ..
            sunsaturn:/website/vuser#


            We can clearly see here that postfix changed uid correctly as defined by
            virtual_uid_maps entry but ignored virtual_gid_maps completely.


            Hope this is detailed enough, let me know if you need anything more.
            Seems to me gid problem is because effective userid is being changed
            but effective gid is not, I am not sure if this is just freebsd related or
            not.

            As for first problem unable to create initial directory, my suggestion is
            if mkdir fails under effective UID first time, then add if statement to
            change effective uid to root, make first directory, chown it to effective
            user id, then repeat.


            Dan.





            On Tue, 30 Nov 2010, Brian Evans - Postfix List wrote:

            > On 11/30/2010 11:49 AM, Dan wrote:
            >>
            >> On freebsd 8.0: standard install from ports collection:
            >>
            >> 1) virtual_gid_maps problems #GID does not appear to be working
            >> virtual_gid_maps = mysql:$config_directory/mysql_gids.cf
            >> #virtual_gid_maps = static:2001
            >>
            > Instead of quoting sections of main.cf, please check 'postconf -n' and post
            > that instead.
            > This avoids problems of what Postfix is actually using versus what you claim
            > is right.
            >
            >>
            >> Postfix creates new directories/mail with gid of postfix user only,
            >> completely ignoring virtual_gid_maps. I have tested both static and mysql
            >> configurations, same result.
            >>
            >> 2) Postfix is not changing to root then chown'ing directories to
            >> appropriate virtual_uid_maps. Please see proftpd code as how they
            >> accomplish this. Problem is when you add a new "maildir" to mysql table
            >> that has not existed before, postfix will change euid to the uid of
            >> virtual_uid_maps, then attempt to create directories, which forces sys
            >> admin to make the virtual_base directory mode 777 as it constantly needs to
            >> create directories with new UIDs within there, so just doing a euid change
            >> to uid of virtual_uid_maps is not enough to do the initial create of first
            >> directory.
            >>
            >> Obviously a solution to this is for enduser to create the first directory
            >> ahead of time, but this should really be done server side.
            >>
            >>
            >> Dan.
            >>
            >
            >
          • Dan
            My first time on list I appologise in advance for not just submitting a patch to problem, but I haven t coded C in about 12 years. I realize this would require
            Message 5 of 19 , Nov 30, 2010
            • 0 Attachment
              My first time on list I appologise in advance for not just submitting a
              patch to problem, but I haven't coded C in about 12 years. I realize this
              would require someone to have access to a freebsd machine, patch code, and
              wait for a recompile to test, and I do appreciate time to do this. However
              I have coded a few MTA's in perl linking in C libevent libraries in last
              few years, so I can help where I can.

              Noticed from email test2@... should have been test2@....

              I decided to retire qmail I have been running for last 10 years, its just
              to problematic to maintain anymore especially with ipv6 patches breaking
              rbls, not counting 10 patches needed on top of default source code.
              I was researching postfix against exim, and postfix seems to have biggest
              following, happy to be apart of the group and get a basic webhosting
              solution figured out here with postfix+mysql+courier imap. Have most of it
              implemented now, just a couple quirks to workout :) Love to hear from
              anyone else's experiences with the setup with many users, as I am comming
              from the qmail+vpopmail days...


              Dan.



              On Tue, 30 Nov 2010, Dan wrote:

              >
              > As you request:
              >
              > postfix -n
              >
              > alias_database = hash:/etc/aliases
              > alias_maps = hash:/etc/aliases
              > config_directory = /usr/local/etc/postfix
              > debug_peer_level = 2
              > header_checks = regexp:$config_directory/header_checks
              > home_mailbox = Maildir/
              > html_directory = /usr/local/share/doc/postfix
              > inet_interfaces = all
              > inet_protocols = ipv4, ipv6
              > local_recipient_maps = proxy:unix:passwd.byname $alias_maps
              > mailq_path = /usr/local/bin/mailq
              > manpage_directory = /usr/local/man
              > mydestination = sunsaturn.com sunsaturn.sunsaturn.com localhost test.com
              > mydomain = test.com
              > myhostname = test.com
              > mynetworks = $config_directory/mynetworks
              > mynetworks_style = host
              > myorigin = $myhostname
              > newaliases_path = /usr/local/bin/newaliases
              > non_smtpd_milters = inet:localhost:10026
              > readme_directory = /usr/local/share/doc/postfix
              > relay_domains = permit_sasl_authenticated, permit_mynetworks
              > sample_directory = /usr/local/etc/postfix
              > sender_dependent_default_transport_maps =
              > mysql:$config_directory/mysql_outgoing.cf
              > sendmail_path = /usr/local/sbin/sendmail
              > setgid_group = maildrop
              > smtpd_banner = $myhostname ESMTP
              > smtpd_milters = inet:localhost:10026
              > smtpd_recipient_restrictions = check_sender_access
              > hash:$config_directory/badmailfrom,permit_mynetworks,permit_sasl_authenticated,reject_non_fqdn_hostname,reject_non_fqdn_sender,reject_non_fqdn_recipient,reject_unauth_destination,reject_unauth_pipelining,reject_invalid_hostname,reject_rbl_client
              > bl.spamcop.net,reject_rbl_client zen.spamhaus.org,reject_rbl_client
              > cbl.abuseat.org,reject_rbl_client psbl.surriel.com
              > unknown_local_recipient_reject_code = 550
              > virtual_alias_maps = mysql:$config_directory/mysql_aliases.cf
              > virtual_gid_maps = mysql:$config_directory/mysql_gids.cf
              > virtual_mailbox_base = /website/vuser
              > virtual_mailbox_domains = mysql:$config_directory/mysql_domains.cf
              > virtual_mailbox_limit = 51200000
              > virtual_mailbox_maps = mysql:$config_directory/mysql_mailbox.cf
              > virtual_minimum_uid = 2002
              > virtual_uid_maps = mysql:$config_directory/mysql_uids.cf
              >
              > Mysql relevant table entries:
              >
              > email domain maildir
              > test2@... test2.com test2.com/test2/Maildir/
              >
              > uid gid
              > 2003 2001
              >
              > Great lets start with completely empty /website/vuser:
              > sunsaturn:~# rm -rf /website/vuser/*
              > sunsaturn:~# ls -al /website/vuser/
              > total 4K
              > drwxrwxrwx 2 postfix postfix 512 Nov 30 19:21 .
              > drwxr-xr-x 44 517 wheel 1024 Nov 30 04:10 ..
              > sunsaturn:~# chmod 755 /website/vuser; chown postfix /website/vuser
              > sunsaturn:~# ls -ald /website/vuser/
              > drwxr-xr-x 2 postfix postfix 512 Nov 30 19:21 /website/vuser/
              > sunsaturn:~#
              >
              > Now lets see the permissions problem:
              > sunsaturn:~# echo test| mail test2@...
              > sunsaturn:~# tail -10 /var/log/maillog
              > Nov 30 19:22:52 sunsaturn postfix/pickup[21923]: 3EA8C119C56: uid=0
              > from=<root>
              > Nov 30 19:22:52 sunsaturn postfix/cleanup[23168]: 3EA8C119C56:
              > message-id=<20101201012252.3EA8C119C56@...>
              > Nov 30 19:22:52 sunsaturn dkim-filter[77781]: 3EA8C119C56 ADSP query: missing
              > parameter(s) in policy data
              > Nov 30 19:22:52 sunsaturn dkim-filter[77781]: 3EA8C119C56: no signature data
              > Nov 30 19:22:52 sunsaturn postfix/qmgr[10416]: 3EA8C119C56:
              > from=<root@...>, size=299, nrcpt=1 (queue active)
              > Nov 30 19:22:52 sunsaturn postfix/virtual[23170]: warning: maildir access
              > problem for UID/GID=2003/2001: create maildir file
              > /website/vuser/test2.com/test2/Maildir/tmp/1291166572.P23170.sunsaturn.com:
              > Permission denied
              > Nov 30 19:22:52 sunsaturn postfix/virtual[23170]: warning: perhaps you need
              > to create the maildirs in advance
              > Nov 30 19:22:52 sunsaturn postfix/virtual[23170]: 3EA8C119C56:
              > to=<test2@...>, relay=virtual, delay=0.07, delays=0.03/0.02/0/0.02,
              > dsn=4.2.0, status=deferred (maildir delivery failed: create maildir file
              > /website/vuser/test2.com/test2/Maildir/tmp/1291166572.P23170.sunsaturn.com:
              > Permission denied)
              > sunsaturn:~#
              >
              > Here we see problem for creating first directory under /website/vuser
              >
              > Now lets chmod 777 /website/vuser so that it can create directories under
              > UID/GID=2003/2001 as it wants but in fact see that gid never is 2001.
              > Gid 2001 under my system is vuser:
              > sunsaturn:~# grep 2001 /etc/group
              > vuser:*:2001:
              > sunsaturn:~# chmod 777 /website/vuser; cd /website/vuser
              > sunsaturn:/website/vuser# echo test| mail test2@...
              >
              > How from logs we can see it actually gets delivered:
              > Nov 30 19:28:03 sunsaturn postfix/qmgr[10416]: DC276119C60:
              > from=<root@...>, size=299, nrcpt=1 (queue active)
              > Nov 30 19:28:03 sunsaturn postfix/virtual[23237]: DC276119C60:
              > to=<test2@...>, relay=virtual, delay=0.01, delays=0.01/0/0/0,
              > dsn=2.0.0, status=sent (delivered to maildir)
              > Nov 30 19:28:03 sunsaturn postfix/qmgr[10416]: DC276119C60: removed
              > Nov 30 19:29:03 sunsaturn postfix/qmgr[10416]: 3EA8C119C56:
              > from=<root@...>, size=299, nrcpt=1 (queue active)
              > Nov 30 19:29:03 sunsaturn postfix/virtual[23237]: 3EA8C119C56:
              > to=<test2@...>, relay=virtual, delay=372, delays=372/0/0/0, dsn=2.0.0,
              > status=sent (delivered to maildir)
              > Nov 30 19:29:03 sunsaturn postfix/qmgr[10416]: 3EA8C119C56: removed
              >
              > So lets check file structure:
              >
              > sunsaturn:/website/vuser# ls -al
              > total 6K
              > drwxrwxrwx 3 postfix postfix 512 Nov 30 19:28 .
              > drwxr-xr-x 44 517 wheel 1024 Nov 30 04:10 ..
              > drwx------ 3 2003 postfix 512 Nov 30 19:28 test2.com
              > sunsaturn:/website/vuser# ls
              > test2.com
              > sunsaturn:/website/vuser# find test2.com|xargs ls -al
              > -rw------- 1 2003 postfix 347 Nov 30 19:28
              > test2.com/test2/Maildir/new/1291166883.V59Ib97008M906598.sunsaturn.com
              > -rw------- 1 2003 postfix 347 Nov 30 19:29
              > test2.com/test2/Maildir/new/1291166943.V59Ib97001M911353.sunsaturn.com
              >
              > test2.com:
              > total 6
              > drwx------ 3 2003 postfix 512 Nov 30 19:28 .
              > drwxrwxrwx 3 postfix postfix 512 Nov 30 19:28 ..
              > drwx------ 3 2003 postfix 512 Nov 30 19:28 test2
              >
              > test2.com/test2:
              > total 6
              > drwx------ 3 2003 postfix 512 Nov 30 19:28 .
              > drwx------ 3 2003 postfix 512 Nov 30 19:28 ..
              > drwx------ 5 2003 postfix 512 Nov 30 19:28 Maildir
              >
              > test2.com/test2/Maildir:
              > total 10
              > drwx------ 5 2003 postfix 512 Nov 30 19:28 .
              > drwx------ 3 2003 postfix 512 Nov 30 19:28 ..
              > drwx------ 2 2003 postfix 512 Nov 30 19:28 cur
              > drwx------ 2 2003 postfix 512 Nov 30 19:29 new
              > drwx------ 2 2003 postfix 512 Nov 30 19:29 tmp
              >
              > test2.com/test2/Maildir/cur:
              > total 4
              > drwx------ 2 2003 postfix 512 Nov 30 19:28 .
              > drwx------ 5 2003 postfix 512 Nov 30 19:28 ..
              >
              > test2.com/test2/Maildir/new:
              > total 8
              > drwx------ 2 2003 postfix 512 Nov 30 19:29 .
              > drwx------ 5 2003 postfix 512 Nov 30 19:28 ..
              > -rw------- 1 2003 postfix 347 Nov 30 19:28
              > 1291166883.V59Ib97008M906598.sunsaturn.com
              > -rw------- 1 2003 postfix 347 Nov 30 19:29
              > 1291166943.V59Ib97001M911353.sunsaturn.com
              >
              > test2.com/test2/Maildir/tmp:
              > total 4
              > drwx------ 2 2003 postfix 512 Nov 30 19:29 .
              > drwx------ 5 2003 postfix 512 Nov 30 19:28 ..
              > sunsaturn:/website/vuser#
              >
              >
              > We can clearly see here that postfix changed uid correctly as defined by
              > virtual_uid_maps entry but ignored virtual_gid_maps completely.
              >
              >
              > Hope this is detailed enough, let me know if you need anything more.
              > Seems to me gid problem is because effective userid is being changed
              > but effective gid is not, I am not sure if this is just freebsd related or
              > not.
              >
              > As for first problem unable to create initial directory, my suggestion is if
              > mkdir fails under effective UID first time, then add if statement to change
              > effective uid to root, make first directory, chown it to effective user id,
              > then repeat.
              >
              >
              > Dan.
              >
              >
              >
              >
              >
              > On Tue, 30 Nov 2010, Brian Evans - Postfix List wrote:
              >
              >> On 11/30/2010 11:49 AM, Dan wrote:
              >>>
              >>> On freebsd 8.0: standard install from ports collection:
              >>>
              >>> 1) virtual_gid_maps problems #GID does not appear to be working
              >>> virtual_gid_maps = mysql:$config_directory/mysql_gids.cf
              >>> #virtual_gid_maps = static:2001
              >>>
              >> Instead of quoting sections of main.cf, please check 'postconf -n' and post
              >> that instead.
              >> This avoids problems of what Postfix is actually using versus what you
              >> claim is right.
              >>
              >>>
              >>> Postfix creates new directories/mail with gid of postfix user only,
              >>> completely ignoring virtual_gid_maps. I have tested both static and mysql
              >>> configurations, same result.
              >>>
              >>> 2) Postfix is not changing to root then chown'ing directories to
              >>> appropriate virtual_uid_maps. Please see proftpd code as how they
              >>> accomplish this. Problem is when you add a new "maildir" to mysql table
              >>> that has not existed before, postfix will change euid to the uid of
              >>> virtual_uid_maps, then attempt to create directories, which forces sys
              >>> admin to make the virtual_base directory mode 777 as it constantly needs
              >>> to create directories with new UIDs within there, so just doing a euid
              >>> change to uid of virtual_uid_maps is not enough to do the initial create
              >>> of first directory.
              >>>
              >>> Obviously a solution to this is for enduser to create the first directory
              >>> ahead of time, but this should really be done server side.
              >>>
              >>>
              >>> Dan.
              >>>
              >>
              >>
              >
            • Victor Duchovni
              ... And in /etc/group, what is group 2001? ... Prove this by posting the output of: # tmp=$(mktemp /tmp/test.XXXXXX) # chown 2003:2001 $tmp # ls -l $tmp #
              Message 6 of 19 , Nov 30, 2010
              • 0 Attachment
                On Tue, Nov 30, 2010 at 07:39:39PM -0600, Dan wrote:

                > virtual_gid_maps = mysql:$config_directory/mysql_gids.cf
                > virtual_minimum_uid = 2002
                > virtual_uid_maps = mysql:$config_directory/mysql_uids.cf
                >
                > Mysql relevant table entries:
                >
                > email domain maildir
                > test2@... test2.com test2.com/test2/Maildir/
                >
                > uid gid
                > 2003 2001

                And in /etc/group, what is group 2001?

                > Now lets chmod 777 /website/vuser so that it can create directories under
                > UID/GID=2003/2001 as it wants but in fact see that gid never is 2001.
                > Gid 2001 under my system is vuser:
                > sunsaturn:~# grep 2001 /etc/group
                > vuser:*:2001:

                Prove this by posting the output of:

                # tmp=$(mktemp /tmp/test.XXXXXX)
                # chown 2003:2001 "$tmp"
                # ls -l "$tmp"
                # rm "$tmp"

                > sunsaturn:~# chmod 777 /website/vuser; cd /website/vuser

                Never use world-writable directories in this context.

                > Nov 30 19:28:03 sunsaturn postfix/virtual[23237]: DC276119C60:
                > to=<test2@...>, relay=virtual, delay=0.01, delays=0.01/0/0/0,
                > dsn=2.0.0, status=sent (delivered to maildir)
                > Nov 30 19:29:03 sunsaturn postfix/virtual[23237]: 3EA8C119C56:
                > to=<test2@...>, relay=virtual, delay=372, delays=372/0/0/0,
                > dsn=2.0.0, status=sent (delivered to maildir)

                > -rw------- 1 2003 postfix 347 Nov 30 19:28
                > test2.com/test2/Maildir/new/1291166883.V59Ib97008M906598.sunsaturn.com
                > -rw------- 1 2003 postfix 347 Nov 30 19:29
                > test2.com/test2/Maildir/new/1291166943.V59Ib97001M911353.sunsaturn.com

                Well Postfix asks the operating system nicely by setting its effective
                uid and gid. If the operating system does not cooperate, you need to
                find out why.

                src/virtual/mailbox.c:deliver_mailbox():

                /* Look up the mailbox owner rights. Defer in case of trouble. */
                uid_res = mail_addr_find(virtual_uid_maps, state.msg_attr.user,
                IGNORE_EXTENSION);
                if (uid_res == 0) { /* error handling */ }
                if ((n = atol(uid_res)) < var_virt_minimum_uid) { /* error handling */ }
                usr_attr.uid = (uid_t) n;

                /* Look up the mailbox group rights. Defer in case of trouble. */
                gid_res = mail_addr_find(virtual_gid_maps, state.msg_attr.user,
                IGNORE_EXTENSION);
                if (gid_res == 0) { /* error handling */ }
                if ((n = atol(gid_res)) <= 0) { /* error handling */ }
                usr_attr.gid = (gid_t) n;

                if (msg_verbose)
                msg_info("%s[%d]: set user_attr: %s, uid = %u, gid = %u",
                myname, state.level, usr_attr.mailbox,
                (unsigned) usr_attr.uid, (unsigned) usr_attr.gid);

                You can configure "virtual -v" in master.cf to see the uid/gid logged.

                /* Deliver to mailbox or to maildir. */
                #define LAST_CHAR(s) (s[strlen(s) - 1])

                if (LAST_CHAR(usr_attr.mailbox) == '/')
                *statusp = deliver_maildir(state, usr_attr);
                else
                *statusp = deliver_mailbox_file(state, usr_attr);

                src/virtual/mailbox.c:deliver_maildir():

                set_eugid(usr_attr.uid, usr_attr.gid);

                /* Creates files, writes data, ... */

                set_eugid(var_owner_uid, var_owner_gid);

                --
                Viktor.
              • Dan
                #####################Chmod 755 mkdir problem######################### Ok enabling virtual -v and nuking /website/vuser with chmod 755 on it we have: Nov 30
                Message 7 of 19 , Nov 30, 2010
                • 0 Attachment
                  #####################Chmod 755 mkdir problem#########################

                  Ok enabling "virtual -v" and nuking /website/vuser with chmod 755 on it we
                  have:
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: deliver_mailbox[2]:
                  recip test2@... deliver test2@...
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_get_active:
                  attempting to connect to host unix:/tmp/mysql.sock
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                  connection to host unix:/tmp/mysql.sock
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                  query from host unix:/tmp/mysql.sock
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_lookup:
                  retrieved 1 rows
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: maps_find:
                  virtual_mailbox_maps:
                  mysql:/usr/local/etc/postfix/mysql_mailbox.cf(0,lock|no_regsub|no_proxy|no_unauth):
                  test2@... = test2.com/test2/Maildir/
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: mail_addr_find:
                  test2@... -> test2.com/test2/Maildir/
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_get_active:
                  attempting to connect to host unix:/tmp/mysql.sock
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                  connection to host unix:/tmp/mysql.sock
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                  query from host unix:/tmp/mysql.sock
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_lookup:
                  retrieved 1 rows
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: maps_find:
                  virtual_uid_maps:
                  mysql:/usr/local/etc/postfix/mysql_uids.cf(0,lock|no_regsub|no_proxy|no_unauth):
                  test2@... = 2003
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: mail_addr_find:
                  test2@... -> 2003
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_get_active:
                  attempting to connect to host unix:/tmp/mysql.sock
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                  connection to host unix:/tmp/mysql.sock
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                  query from host unix:/tmp/mysql.sock
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_lookup:
                  retrieved 1 rows
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: maps_find:
                  virtual_gid_maps:
                  mysql:/usr/local/etc/postfix/mysql_gids.cf(0,lock|no_regsub|no_proxy|no_unauth):
                  test2@... = 2001
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: mail_addr_find:
                  test2@... -> 2001
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: deliver_mailbox[2]: set
                  user_attr: /website/vuser/test2.com/test2/Maildir/, uid = 2003, gid = 2001
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: deliver_maildir[3]:
                  recip test2@... deliver test2@...
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: set_eugid: euid 2003
                  egid 2001
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: set_eugid: euid 125 egid
                  125
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: warning: maildir access
                  problem for UID/GID=2003/2001: create maildir file
                  /website/vuser/test2.com/test2/Maildir/tmp/1291172927.P25625.sunsaturn.com:
                  Permission denied
                  Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: warning: perhaps you
                  need to create the maildirs in advance

                  #####################Chmod 777 GID problem#########################

                  lets go back to chmod 777 /website/vuser and check GID issues:

                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_mailbox[2]:
                  recip test2@... deliver test2@...
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_get_active:
                  attempting to connect to host unix:/tmp/mysql.sock
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                  connection to host unix:/tmp/mysql.sock
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                  query from host unix:/tmp/mysql.sock
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_lookup:
                  retrieved 1 rows
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: maps_find:
                  virtual_mailbox_maps:
                  mysql:/usr/local/etc/postfix/mysql_mailbox.cf(0,lock|no_regsub|no_proxy|no_unauth):
                  test2@... = test2.com/test2/Maildir/
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: mail_addr_find:
                  test2@... -> test2.com/test2/Maildir/
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_get_active:
                  attempting to connect to host unix:/tmp/mysql.sock
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                  connection to host unix:/tmp/mysql.sock
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                  query from host unix:/tmp/mysql.sock
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_lookup:
                  retrieved 1 rows
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: maps_find:
                  virtual_uid_maps:
                  mysql:/usr/local/etc/postfix/mysql_uids.cf(0,lock|no_regsub|no_proxy|no_unauth):
                  test2@... = 2003
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: mail_addr_find:
                  test2@... -> 2003
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_get_active:
                  attempting to connect to host unix:/tmp/mysql.sock
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                  connection to host unix:/tmp/mysql.sock
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                  query from host unix:/tmp/mysql.sock
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_lookup:
                  retrieved 1 rows
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: maps_find:
                  virtual_gid_maps:
                  mysql:/usr/local/etc/postfix/mysql_gids.cf(0,lock|no_regsub|no_proxy|no_unauth):
                  test2@... = 2001
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: mail_addr_find:
                  test2@... -> 2001
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_mailbox[2]: set
                  user_attr: /website/vuser/test2.com/test2/Maildir/, uid = 2003, gid = 2001
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_maildir[3]:
                  recip test2@... deliver test2@...
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: set_eugid: euid 2003
                  egid 2001
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: set_eugid: euid 125 egid
                  125
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: 6FE80119C5B:
                  to=<test2@...>, relay=virtual, delay=0.06, delays=0.03/0.02/0/0.01,
                  dsn=2.0.0, status=sent (delivered to maildir)
                  Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_request_final:
                  send: "" 0


                  > src/virtual/mailbox.c:deliver_maildir():
                  >
                  > set_eugid(usr_attr.uid, usr_attr.gid);
                  >
                  > /* Creates files, writes data, ... */

                  I can only think there is an issue here with usr_attr.gid for GID problem.

                  For creating initial directory it should set_eugid(0,0); create
                  directory then change permissions on it because how are we suppose to not
                  777 the directory if everytime it creates a new file in there its owned by
                  uid 2002 then 2003 then 2004 and so on...

                  Code is fine way it is except for initial creation.

                  Another note: I beleive you made a typo?
                  > src/virtual/mailbox.c:deliver_maildir():
                  should be src/virtual/maildir.c:deliver_maildir():

                  Lets modify src/virtual/maildir.c to just touch a /tmp/file after
                  set_eugid(usr_attr.uid, usr_attr.gid);
                  by placing
                  system("/usr/bin/touch /tmp/gid_debug.txt");

                  right after and see what /tmp/gid_debug.txt looks like.

                  sunsaturn:/usr/ports/mail/postfix-current# echo test|mail test2@...
                  sunsaturn:/usr/ports/mail/postfix-current# ls -al /tmp/gid*
                  -rw------- 1 2003 wheel 0 Nov 30 21:54 /tmp/gid_debug.txt
                  sunsaturn:/usr/ports/mail/postfix-current#

                  so we definately have an issue with usr_attr.gid here somewhere.


                  for your own reference:

                  sunsaturn:/website/vuser# tmp=$(mktemp /tmp/test.XXXXXX)
                  sunsaturn:/website/vuser# chown 2003:2001 "$tmp"
                  sunsaturn:/website/vuser# ls -l "$tmp"
                  -rw------- 1 2003 vuser 0 Nov 30 21:19 /tmp/test.Kev8V1
                  sunsaturn:/website/vuser# rm "$tmp"


                  Dan.



                  On Tue, 30 Nov 2010, Victor Duchovni wrote:

                  > On Tue, Nov 30, 2010 at 07:39:39PM -0600, Dan wrote:
                  >
                  >> virtual_gid_maps = mysql:$config_directory/mysql_gids.cf
                  >> virtual_minimum_uid = 2002
                  >> virtual_uid_maps = mysql:$config_directory/mysql_uids.cf
                  >>
                  >> Mysql relevant table entries:
                  >>
                  >> email domain maildir
                  >> test2@... test2.com test2.com/test2/Maildir/
                  >>
                  >> uid gid
                  >> 2003 2001
                  >
                  > And in /etc/group, what is group 2001?
                  >
                  >> Now lets chmod 777 /website/vuser so that it can create directories under
                  >> UID/GID=2003/2001 as it wants but in fact see that gid never is 2001.
                  >> Gid 2001 under my system is vuser:
                  >> sunsaturn:~# grep 2001 /etc/group
                  >> vuser:*:2001:
                  >
                  > Prove this by posting the output of:
                  >
                  > # tmp=$(mktemp /tmp/test.XXXXXX)
                  > # chown 2003:2001 "$tmp"
                  > # ls -l "$tmp"
                  > # rm "$tmp"
                  >
                  >> sunsaturn:~# chmod 777 /website/vuser; cd /website/vuser
                  >
                  > Never use world-writable directories in this context.
                  >
                  >> Nov 30 19:28:03 sunsaturn postfix/virtual[23237]: DC276119C60:
                  >> to=<test2@...>, relay=virtual, delay=0.01, delays=0.01/0/0/0,
                  >> dsn=2.0.0, status=sent (delivered to maildir)
                  >> Nov 30 19:29:03 sunsaturn postfix/virtual[23237]: 3EA8C119C56:
                  >> to=<test2@...>, relay=virtual, delay=372, delays=372/0/0/0,
                  >> dsn=2.0.0, status=sent (delivered to maildir)
                  >
                  >> -rw------- 1 2003 postfix 347 Nov 30 19:28
                  >> test2.com/test2/Maildir/new/1291166883.V59Ib97008M906598.sunsaturn.com
                  >> -rw------- 1 2003 postfix 347 Nov 30 19:29
                  >> test2.com/test2/Maildir/new/1291166943.V59Ib97001M911353.sunsaturn.com
                  >
                  > Well Postfix asks the operating system nicely by setting its effective
                  > uid and gid. If the operating system does not cooperate, you need to
                  > find out why.
                  >
                  > src/virtual/mailbox.c:deliver_mailbox():
                  >
                  > /* Look up the mailbox owner rights. Defer in case of trouble. */
                  > uid_res = mail_addr_find(virtual_uid_maps, state.msg_attr.user,
                  > IGNORE_EXTENSION);
                  > if (uid_res == 0) { /* error handling */ }
                  > if ((n = atol(uid_res)) < var_virt_minimum_uid) { /* error handling */ }
                  > usr_attr.uid = (uid_t) n;
                  >
                  > /* Look up the mailbox group rights. Defer in case of trouble. */
                  > gid_res = mail_addr_find(virtual_gid_maps, state.msg_attr.user,
                  > IGNORE_EXTENSION);
                  > if (gid_res == 0) { /* error handling */ }
                  > if ((n = atol(gid_res)) <= 0) { /* error handling */ }
                  > usr_attr.gid = (gid_t) n;
                  >
                  > if (msg_verbose)
                  > msg_info("%s[%d]: set user_attr: %s, uid = %u, gid = %u",
                  > myname, state.level, usr_attr.mailbox,
                  > (unsigned) usr_attr.uid, (unsigned) usr_attr.gid);
                  >
                  > You can configure "virtual -v" in master.cf to see the uid/gid logged.
                  >
                  > /* Deliver to mailbox or to maildir. */
                  > #define LAST_CHAR(s) (s[strlen(s) - 1])
                  >
                  > if (LAST_CHAR(usr_attr.mailbox) == '/')
                  > *statusp = deliver_maildir(state, usr_attr);
                  > else
                  > *statusp = deliver_mailbox_file(state, usr_attr);
                  >
                  > src/virtual/mailbox.c:deliver_maildir():
                  >
                  > set_eugid(usr_attr.uid, usr_attr.gid);
                  >
                  > /* Creates files, writes data, ... */
                  >
                  > set_eugid(var_owner_uid, var_owner_gid);
                  >
                  > --
                  > Viktor.
                  >
                • Dan
                  maildir.c mods: msg_info( TESTING1 set_eugid: euid %ld egid %ld , (long) usr_attr.uid, (long) usr_attr.gid); set_eugid(usr_attr.uid, usr_attr.gid);
                  Message 8 of 19 , Nov 30, 2010
                  • 0 Attachment
                    maildir.c mods:

                    msg_info("TESTING1 set_eugid: euid %ld egid %ld", (long) usr_attr.uid,
                    (long) usr_attr.gid);
                    set_eugid(usr_attr.uid, usr_attr.gid);
                    msg_info("TESTING2 set_eugid: euid %ld egid %ld", (long) usr_attr.uid,
                    (long) usr_attr.gid);


                    Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: deliver_maildir[3]:
                    recip test2@... deliver test2@...
                    Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: TESTING1 set_eugid: euid
                    2003 egid 2001
                    Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: set_eugid: euid 2003
                    egid 2001
                    Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: TESTING2 set_eugid: euid
                    2003 egid 2001
                    Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: set_eugid: euid 125 egid
                    125

                    Appears to be a freebsd issue with GID from what I can see if this works
                    for linux users.

                    Either way I was hoping for a mod on maildir.c for initial create of
                    directory as root.

                    Can debug gid issue more if you like to get freebsd to play nice, but uid
                    is only thing that will matter regardless for permissions, but be nice to fix anyways.



                    Dan.



                    On Tue, 30 Nov 2010, Dan wrote:

                    >
                    > #####################Chmod 755 mkdir problem#########################
                    >
                    > Ok enabling "virtual -v" and nuking /website/vuser with chmod 755 on it we
                    > have:
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: deliver_mailbox[2]: recip
                    > test2@... deliver test2@...
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_get_active:
                    > attempting to connect to host unix:/tmp/mysql.sock
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                    > connection to host unix:/tmp/mysql.sock
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                    > query from host unix:/tmp/mysql.sock
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_lookup:
                    > retrieved 1 rows
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: maps_find:
                    > virtual_mailbox_maps:
                    > mysql:/usr/local/etc/postfix/mysql_mailbox.cf(0,lock|no_regsub|no_proxy|no_unauth):
                    > test2@... = test2.com/test2/Maildir/
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: mail_addr_find:
                    > test2@... -> test2.com/test2/Maildir/
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_get_active:
                    > attempting to connect to host unix:/tmp/mysql.sock
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                    > connection to host unix:/tmp/mysql.sock
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                    > query from host unix:/tmp/mysql.sock
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_lookup:
                    > retrieved 1 rows
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: maps_find:
                    > virtual_uid_maps:
                    > mysql:/usr/local/etc/postfix/mysql_uids.cf(0,lock|no_regsub|no_proxy|no_unauth):
                    > test2@... = 2003
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: mail_addr_find:
                    > test2@... -> 2003
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_get_active:
                    > attempting to connect to host unix:/tmp/mysql.sock
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                    > connection to host unix:/tmp/mysql.sock
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                    > query from host unix:/tmp/mysql.sock
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_lookup:
                    > retrieved 1 rows
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: maps_find:
                    > virtual_gid_maps:
                    > mysql:/usr/local/etc/postfix/mysql_gids.cf(0,lock|no_regsub|no_proxy|no_unauth):
                    > test2@... = 2001
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: mail_addr_find:
                    > test2@... -> 2001
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: deliver_mailbox[2]: set
                    > user_attr: /website/vuser/test2.com/test2/Maildir/, uid = 2003, gid = 2001
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: deliver_maildir[3]: recip
                    > test2@... deliver test2@...
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: set_eugid: euid 2003 egid
                    > 2001
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: set_eugid: euid 125 egid
                    > 125
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: warning: maildir access
                    > problem for UID/GID=2003/2001: create maildir file
                    > /website/vuser/test2.com/test2/Maildir/tmp/1291172927.P25625.sunsaturn.com:
                    > Permission denied
                    > Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: warning: perhaps you need
                    > to create the maildirs in advance
                    >
                    > #####################Chmod 777 GID problem#########################
                    >
                    > lets go back to chmod 777 /website/vuser and check GID issues:
                    >
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_mailbox[2]: recip
                    > test2@... deliver test2@...
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_get_active:
                    > attempting to connect to host unix:/tmp/mysql.sock
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                    > connection to host unix:/tmp/mysql.sock
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                    > query from host unix:/tmp/mysql.sock
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_lookup:
                    > retrieved 1 rows
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: maps_find:
                    > virtual_mailbox_maps:
                    > mysql:/usr/local/etc/postfix/mysql_mailbox.cf(0,lock|no_regsub|no_proxy|no_unauth):
                    > test2@... = test2.com/test2/Maildir/
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: mail_addr_find:
                    > test2@... -> test2.com/test2/Maildir/
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_get_active:
                    > attempting to connect to host unix:/tmp/mysql.sock
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                    > connection to host unix:/tmp/mysql.sock
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                    > query from host unix:/tmp/mysql.sock
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_lookup:
                    > retrieved 1 rows
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: maps_find:
                    > virtual_uid_maps:
                    > mysql:/usr/local/etc/postfix/mysql_uids.cf(0,lock|no_regsub|no_proxy|no_unauth):
                    > test2@... = 2003
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: mail_addr_find:
                    > test2@... -> 2003
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_get_active:
                    > attempting to connect to host unix:/tmp/mysql.sock
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                    > connection to host unix:/tmp/mysql.sock
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                    > query from host unix:/tmp/mysql.sock
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_lookup:
                    > retrieved 1 rows
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: maps_find:
                    > virtual_gid_maps:
                    > mysql:/usr/local/etc/postfix/mysql_gids.cf(0,lock|no_regsub|no_proxy|no_unauth):
                    > test2@... = 2001
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: mail_addr_find:
                    > test2@... -> 2001
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_mailbox[2]: set
                    > user_attr: /website/vuser/test2.com/test2/Maildir/, uid = 2003, gid = 2001
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_maildir[3]: recip
                    > test2@... deliver test2@...
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: set_eugid: euid 2003 egid
                    > 2001
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: set_eugid: euid 125 egid
                    > 125
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: 6FE80119C5B:
                    > to=<test2@...>, relay=virtual, delay=0.06, delays=0.03/0.02/0/0.01,
                    > dsn=2.0.0, status=sent (delivered to maildir)
                    > Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_request_final:
                    > send: "" 0
                    >
                    >
                    >> src/virtual/mailbox.c:deliver_maildir():
                    >>
                    >> set_eugid(usr_attr.uid, usr_attr.gid);
                    >>
                    >> /* Creates files, writes data, ... */
                    >
                    > I can only think there is an issue here with usr_attr.gid for GID problem.
                    >
                    > For creating initial directory it should set_eugid(0,0); create directory
                    > then change permissions on it because how are we suppose to not 777 the
                    > directory if everytime it creates a new file in there its owned by uid 2002
                    > then 2003 then 2004 and so on...
                    >
                    > Code is fine way it is except for initial creation.
                    >
                    > Another note: I beleive you made a typo?
                    >> src/virtual/mailbox.c:deliver_maildir():
                    > should be src/virtual/maildir.c:deliver_maildir():
                    >
                    > Lets modify src/virtual/maildir.c to just touch a /tmp/file after
                    > set_eugid(usr_attr.uid, usr_attr.gid);
                    > by placing
                    > system("/usr/bin/touch /tmp/gid_debug.txt");
                    >
                    > right after and see what /tmp/gid_debug.txt looks like.
                    >
                    > sunsaturn:/usr/ports/mail/postfix-current# echo test|mail test2@...
                    > sunsaturn:/usr/ports/mail/postfix-current# ls -al /tmp/gid*
                    > -rw------- 1 2003 wheel 0 Nov 30 21:54 /tmp/gid_debug.txt
                    > sunsaturn:/usr/ports/mail/postfix-current#
                    >
                    > so we definately have an issue with usr_attr.gid here somewhere.
                    >
                    >
                    > for your own reference:
                    >
                    > sunsaturn:/website/vuser# tmp=$(mktemp /tmp/test.XXXXXX)
                    > sunsaturn:/website/vuser# chown 2003:2001 "$tmp"
                    > sunsaturn:/website/vuser# ls -l "$tmp"
                    > -rw------- 1 2003 vuser 0 Nov 30 21:19 /tmp/test.Kev8V1
                    > sunsaturn:/website/vuser# rm "$tmp"
                    >
                    >
                    > Dan.
                    >
                    >
                    >
                    > On Tue, 30 Nov 2010, Victor Duchovni wrote:
                    >
                    >> On Tue, Nov 30, 2010 at 07:39:39PM -0600, Dan wrote:
                    >>
                    >>> virtual_gid_maps = mysql:$config_directory/mysql_gids.cf
                    >>> virtual_minimum_uid = 2002
                    >>> virtual_uid_maps = mysql:$config_directory/mysql_uids.cf
                    >>>
                    >>> Mysql relevant table entries:
                    >>>
                    >>> email domain maildir
                    >>> test2@... test2.com test2.com/test2/Maildir/
                    >>>
                    >>> uid gid
                    >>> 2003 2001
                    >>
                    >> And in /etc/group, what is group 2001?
                    >>
                    >>> Now lets chmod 777 /website/vuser so that it can create directories under
                    >>> UID/GID=2003/2001 as it wants but in fact see that gid never is 2001.
                    >>> Gid 2001 under my system is vuser:
                    >>> sunsaturn:~# grep 2001 /etc/group
                    >>> vuser:*:2001:
                    >>
                    >> Prove this by posting the output of:
                    >>
                    >> # tmp=$(mktemp /tmp/test.XXXXXX)
                    >> # chown 2003:2001 "$tmp"
                    >> # ls -l "$tmp"
                    >> # rm "$tmp"
                    >>
                    >>> sunsaturn:~# chmod 777 /website/vuser; cd /website/vuser
                    >>
                    >> Never use world-writable directories in this context.
                    >>
                    >>> Nov 30 19:28:03 sunsaturn postfix/virtual[23237]: DC276119C60:
                    >>> to=<test2@...>, relay=virtual, delay=0.01, delays=0.01/0/0/0,
                    >>> dsn=2.0.0, status=sent (delivered to maildir)
                    >>> Nov 30 19:29:03 sunsaturn postfix/virtual[23237]: 3EA8C119C56:
                    >>> to=<test2@...>, relay=virtual, delay=372, delays=372/0/0/0,
                    >>> dsn=2.0.0, status=sent (delivered to maildir)
                    >>
                    >>> -rw------- 1 2003 postfix 347 Nov 30 19:28
                    >>> test2.com/test2/Maildir/new/1291166883.V59Ib97008M906598.sunsaturn.com
                    >>> -rw------- 1 2003 postfix 347 Nov 30 19:29
                    >>> test2.com/test2/Maildir/new/1291166943.V59Ib97001M911353.sunsaturn.com
                    >>
                    >> Well Postfix asks the operating system nicely by setting its effective
                    >> uid and gid. If the operating system does not cooperate, you need to
                    >> find out why.
                    >>
                    >> src/virtual/mailbox.c:deliver_mailbox():
                    >>
                    >> /* Look up the mailbox owner rights. Defer in case of trouble. */
                    >> uid_res = mail_addr_find(virtual_uid_maps, state.msg_attr.user,
                    >> IGNORE_EXTENSION);
                    >> if (uid_res == 0) { /* error handling */ }
                    >> if ((n = atol(uid_res)) < var_virt_minimum_uid) { /* error handling */
                    >> }
                    >> usr_attr.uid = (uid_t) n;
                    >>
                    >> /* Look up the mailbox group rights. Defer in case of trouble. */
                    >> gid_res = mail_addr_find(virtual_gid_maps, state.msg_attr.user,
                    >> IGNORE_EXTENSION);
                    >> if (gid_res == 0) { /* error handling */ }
                    >> if ((n = atol(gid_res)) <= 0) { /* error handling */ }
                    >> usr_attr.gid = (gid_t) n;
                    >>
                    >> if (msg_verbose)
                    >> msg_info("%s[%d]: set user_attr: %s, uid = %u, gid = %u",
                    >> myname, state.level, usr_attr.mailbox,
                    >> (unsigned) usr_attr.uid, (unsigned) usr_attr.gid);
                    >>
                    >> You can configure "virtual -v" in master.cf to see the uid/gid logged.
                    >>
                    >> /* Deliver to mailbox or to maildir. */
                    >> #define LAST_CHAR(s) (s[strlen(s) - 1])
                    >>
                    >> if (LAST_CHAR(usr_attr.mailbox) == '/')
                    >> *statusp = deliver_maildir(state, usr_attr);
                    >> else
                    >> *statusp = deliver_mailbox_file(state, usr_attr);
                    >>
                    >> src/virtual/mailbox.c:deliver_maildir():
                    >>
                    >> set_eugid(usr_attr.uid, usr_attr.gid);
                    >>
                    >> /* Creates files, writes data, ... */
                    >>
                    >> set_eugid(var_owner_uid, var_owner_gid);
                    >>
                    >> --
                    >> Viktor.
                    >>
                    >
                  • Victor Duchovni
                    ... FreeBSD is silently failing to change the effective GID, or the filesystem assigns file groups in an unexpected way. Do you have any security features in
                    Message 9 of 19 , Nov 30, 2010
                    • 0 Attachment
                      On Tue, Nov 30, 2010 at 10:26:20PM -0600, Dan wrote:

                      > maildir.c mods:
                      >
                      > msg_info("TESTING1 set_eugid: euid %ld egid %ld", (long) usr_attr.uid,
                      > (long) usr_attr.gid);
                      > set_eugid(usr_attr.uid, usr_attr.gid);
                      > msg_info("TESTING2 set_eugid: euid %ld egid %ld", (long) usr_attr.uid,
                      > (long) usr_attr.gid);
                      >
                      >
                      > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: deliver_maildir[3]: recip
                      > test2@... deliver test2@...
                      > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: TESTING1 set_eugid: euid
                      > 2003 egid 2001
                      > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: set_eugid: euid 2003 egid
                      > 2001
                      > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: TESTING2 set_eugid: euid
                      > 2003 egid 2001
                      > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: set_eugid: euid 125 egid
                      > 125
                      >
                      > Appears to be a freebsd issue with GID from what I can see if this works
                      > for linux users.

                      FreeBSD is silently failing to change the effective GID, or the filesystem
                      assigns file groups in an unexpected way. Do you have any "security"
                      features in your BSD Kernel along the lines of Linux SELinux or AppArmor?

                      > Either way I was hoping for a mod on maildir.c for initial create of
                      > directory as root.

                      No, the directories MUST NOT be created by root. Rather, you must
                      pre-create them or user 2003 needs to own the parent directory in which
                      missing child directories will be created, or in some cases (but not
                      this one) the parent directory can be mode 1777.

                      --
                      Viktor.
                    • Dan
                      Gid inherits top level directory GID? sunsaturn:/website/vuser# rm -rf test2.com sunsaturn:/website/vuser# echo test|mail sdfs@test2.com
                      Message 10 of 19 , Dec 1, 2010
                      • 0 Attachment
                        Gid inherits top level directory GID?

                        sunsaturn:/website/vuser# rm -rf test2.com
                        sunsaturn:/website/vuser# echo test|mail sdfs@...
                        sunsaturn:/website/vuser# ls -al test2.com/test2/Maildir/new/
                        total 6K
                        drwx------ 2 2003 postfix 512 Dec 1 05:45 .
                        drwx------ 5 2003 postfix 512 Dec 1 05:45 ..
                        -rw------- 1 2003 postfix 345 Dec 1 05:45
                        1291203903.V59I11b8c3fM163820.sunsaturn.com
                        sunsaturn:/website/vuser#

                        sunsaturn:/website/vuser# rm -rf test2.com
                        sunsaturn:/website/vuser# mkdir test2.com
                        sunsaturn:/website/vuser# chown 2003:vuser test2.com/
                        sunsaturn:/website/vuser# echo test|mail sdfs@...
                        sunsaturn:/website/vuser# ls -al test2.com/test2/Maildir/new/
                        total 6K
                        drwx------ 2 2003 vuser 512 Dec 1 05:46 .
                        drwx------ 5 2003 vuser 512 Dec 1 05:46 ..
                        -rw------- 1 2003 vuser 345 Dec 1 05:46
                        1291203979.V59I11b8c44M498531.sunsaturn.com
                        sunsaturn:/website/vuser#


                        A patch just to euid change to root, create directory and change
                        permissions of directory to correct uid and gid would solve this issue
                        completely as it seems it inherts gid.


                        Dan.



                        On Tue, 30 Nov 2010, Dan wrote:

                        >
                        >
                        > maildir.c mods:
                        >
                        > msg_info("TESTING1 set_eugid: euid %ld egid %ld", (long) usr_attr.uid,
                        > (long) usr_attr.gid);
                        > set_eugid(usr_attr.uid, usr_attr.gid);
                        > msg_info("TESTING2 set_eugid: euid %ld egid %ld", (long) usr_attr.uid,
                        > (long) usr_attr.gid);
                        >
                        >
                        > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: deliver_maildir[3]: recip
                        > test2@... deliver test2@...
                        > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: TESTING1 set_eugid: euid
                        > 2003 egid 2001
                        > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: set_eugid: euid 2003 egid
                        > 2001
                        > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: TESTING2 set_eugid: euid
                        > 2003 egid 2001
                        > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: set_eugid: euid 125 egid
                        > 125
                        >
                        > Appears to be a freebsd issue with GID from what I can see if this works for
                        > linux users.
                        >
                        > Either way I was hoping for a mod on maildir.c for initial create of
                        > directory as root.
                        >
                        > Can debug gid issue more if you like to get freebsd to play nice, but uid is
                        > only thing that will matter regardless for permissions, but be nice to fix
                        > anyways.
                        >
                        >
                        >
                        > Dan.
                        >
                        >
                        >
                        > On Tue, 30 Nov 2010, Dan wrote:
                        >
                        >>
                        >> #####################Chmod 755 mkdir problem#########################
                        >>
                        >> Ok enabling "virtual -v" and nuking /website/vuser with chmod 755 on it we
                        >> have:
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: deliver_mailbox[2]: recip
                        >> test2@... deliver test2@...
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_get_active:
                        >> attempting to connect to host unix:/tmp/mysql.sock
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                        >> connection to host unix:/tmp/mysql.sock
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                        >> query from host unix:/tmp/mysql.sock
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_lookup:
                        >> retrieved 1 rows
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: maps_find:
                        >> virtual_mailbox_maps:
                        >> mysql:/usr/local/etc/postfix/mysql_mailbox.cf(0,lock|no_regsub|no_proxy|no_unauth):
                        >> test2@... = test2.com/test2/Maildir/
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: mail_addr_find:
                        >> test2@... -> test2.com/test2/Maildir/
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_get_active:
                        >> attempting to connect to host unix:/tmp/mysql.sock
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                        >> connection to host unix:/tmp/mysql.sock
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                        >> query from host unix:/tmp/mysql.sock
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_lookup:
                        >> retrieved 1 rows
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: maps_find:
                        >> virtual_uid_maps:
                        >> mysql:/usr/local/etc/postfix/mysql_uids.cf(0,lock|no_regsub|no_proxy|no_unauth):
                        >> test2@... = 2003
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: mail_addr_find:
                        >> test2@... -> 2003
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_get_active:
                        >> attempting to connect to host unix:/tmp/mysql.sock
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                        >> connection to host unix:/tmp/mysql.sock
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
                        >> query from host unix:/tmp/mysql.sock
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_lookup:
                        >> retrieved 1 rows
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: maps_find:
                        >> virtual_gid_maps:
                        >> mysql:/usr/local/etc/postfix/mysql_gids.cf(0,lock|no_regsub|no_proxy|no_unauth):
                        >> test2@... = 2001
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: mail_addr_find:
                        >> test2@... -> 2001
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: deliver_mailbox[2]: set
                        >> user_attr: /website/vuser/test2.com/test2/Maildir/, uid = 2003, gid = 2001
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: deliver_maildir[3]: recip
                        >> test2@... deliver test2@...
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: set_eugid: euid 2003 egid
                        >> 2001
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: set_eugid: euid 125 egid
                        >> 125
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: warning: maildir access
                        >> problem for UID/GID=2003/2001: create maildir file
                        >> /website/vuser/test2.com/test2/Maildir/tmp/1291172927.P25625.sunsaturn.com:
                        >> Permission denied
                        >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: warning: perhaps you need
                        >> to create the maildirs in advance
                        >>
                        >> #####################Chmod 777 GID problem#########################
                        >>
                        >> lets go back to chmod 777 /website/vuser and check GID issues:
                        >>
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_mailbox[2]: recip
                        >> test2@... deliver test2@...
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_get_active:
                        >> attempting to connect to host unix:/tmp/mysql.sock
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                        >> connection to host unix:/tmp/mysql.sock
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                        >> query from host unix:/tmp/mysql.sock
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_lookup:
                        >> retrieved 1 rows
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: maps_find:
                        >> virtual_mailbox_maps:
                        >> mysql:/usr/local/etc/postfix/mysql_mailbox.cf(0,lock|no_regsub|no_proxy|no_unauth):
                        >> test2@... = test2.com/test2/Maildir/
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: mail_addr_find:
                        >> test2@... -> test2.com/test2/Maildir/
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_get_active:
                        >> attempting to connect to host unix:/tmp/mysql.sock
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                        >> connection to host unix:/tmp/mysql.sock
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                        >> query from host unix:/tmp/mysql.sock
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_lookup:
                        >> retrieved 1 rows
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: maps_find:
                        >> virtual_uid_maps:
                        >> mysql:/usr/local/etc/postfix/mysql_uids.cf(0,lock|no_regsub|no_proxy|no_unauth):
                        >> test2@... = 2003
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: mail_addr_find:
                        >> test2@... -> 2003
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_get_active:
                        >> attempting to connect to host unix:/tmp/mysql.sock
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                        >> connection to host unix:/tmp/mysql.sock
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
                        >> query from host unix:/tmp/mysql.sock
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_lookup:
                        >> retrieved 1 rows
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: maps_find:
                        >> virtual_gid_maps:
                        >> mysql:/usr/local/etc/postfix/mysql_gids.cf(0,lock|no_regsub|no_proxy|no_unauth):
                        >> test2@... = 2001
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: mail_addr_find:
                        >> test2@... -> 2001
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_mailbox[2]: set
                        >> user_attr: /website/vuser/test2.com/test2/Maildir/, uid = 2003, gid = 2001
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_maildir[3]: recip
                        >> test2@... deliver test2@...
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: set_eugid: euid 2003 egid
                        >> 2001
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: set_eugid: euid 125 egid
                        >> 125
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: 6FE80119C5B:
                        >> to=<test2@...>, relay=virtual, delay=0.06, delays=0.03/0.02/0/0.01,
                        >> dsn=2.0.0, status=sent (delivered to maildir)
                        >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_request_final:
                        >> send: "" 0
                        >>
                        >>
                        >>> src/virtual/mailbox.c:deliver_maildir():
                        >>>
                        >>> set_eugid(usr_attr.uid, usr_attr.gid);
                        >>>
                        >>> /* Creates files, writes data, ... */
                        >>
                        >> I can only think there is an issue here with usr_attr.gid for GID problem.
                        >>
                        >> For creating initial directory it should set_eugid(0,0); create directory
                        >> then change permissions on it because how are we suppose to not 777 the
                        >> directory if everytime it creates a new file in there its owned by uid 2002
                        >> then 2003 then 2004 and so on...
                        >>
                        >> Code is fine way it is except for initial creation.
                        >>
                        >> Another note: I beleive you made a typo?
                        >>> src/virtual/mailbox.c:deliver_maildir():
                        >> should be src/virtual/maildir.c:deliver_maildir():
                        >>
                        >> Lets modify src/virtual/maildir.c to just touch a /tmp/file after
                        >> set_eugid(usr_attr.uid, usr_attr.gid);
                        >> by placing
                        >> system("/usr/bin/touch /tmp/gid_debug.txt");
                        >>
                        >> right after and see what /tmp/gid_debug.txt looks like.
                        >>
                        >> sunsaturn:/usr/ports/mail/postfix-current# echo test|mail test2@...
                        >> sunsaturn:/usr/ports/mail/postfix-current# ls -al /tmp/gid*
                        >> -rw------- 1 2003 wheel 0 Nov 30 21:54 /tmp/gid_debug.txt
                        >> sunsaturn:/usr/ports/mail/postfix-current#
                        >>
                        >> so we definately have an issue with usr_attr.gid here somewhere.
                        >>
                        >>
                        >> for your own reference:
                        >>
                        >> sunsaturn:/website/vuser# tmp=$(mktemp /tmp/test.XXXXXX)
                        >> sunsaturn:/website/vuser# chown 2003:2001 "$tmp"
                        >> sunsaturn:/website/vuser# ls -l "$tmp"
                        >> -rw------- 1 2003 vuser 0 Nov 30 21:19 /tmp/test.Kev8V1
                        >> sunsaturn:/website/vuser# rm "$tmp"
                        >>
                        >>
                        >> Dan.
                        >>
                        >>
                        >>
                        >> On Tue, 30 Nov 2010, Victor Duchovni wrote:
                        >>
                        >>> On Tue, Nov 30, 2010 at 07:39:39PM -0600, Dan wrote:
                        >>>
                        >>>> virtual_gid_maps = mysql:$config_directory/mysql_gids.cf
                        >>>> virtual_minimum_uid = 2002
                        >>>> virtual_uid_maps = mysql:$config_directory/mysql_uids.cf
                        >>>>
                        >>>> Mysql relevant table entries:
                        >>>>
                        >>>> email domain maildir
                        >>>> test2@... test2.com test2.com/test2/Maildir/
                        >>>>
                        >>>> uid gid
                        >>>> 2003 2001
                        >>>
                        >>> And in /etc/group, what is group 2001?
                        >>>
                        >>>> Now lets chmod 777 /website/vuser so that it can create directories under
                        >>>> UID/GID=2003/2001 as it wants but in fact see that gid never is 2001.
                        >>>> Gid 2001 under my system is vuser:
                        >>>> sunsaturn:~# grep 2001 /etc/group
                        >>>> vuser:*:2001:
                        >>>
                        >>> Prove this by posting the output of:
                        >>>
                        >>> # tmp=$(mktemp /tmp/test.XXXXXX)
                        >>> # chown 2003:2001 "$tmp"
                        >>> # ls -l "$tmp"
                        >>> # rm "$tmp"
                        >>>
                        >>>> sunsaturn:~# chmod 777 /website/vuser; cd /website/vuser
                        >>>
                        >>> Never use world-writable directories in this context.
                        >>>
                        >>>> Nov 30 19:28:03 sunsaturn postfix/virtual[23237]: DC276119C60:
                        >>>> to=<test2@...>, relay=virtual, delay=0.01, delays=0.01/0/0/0,
                        >>>> dsn=2.0.0, status=sent (delivered to maildir)
                        >>>> Nov 30 19:29:03 sunsaturn postfix/virtual[23237]: 3EA8C119C56:
                        >>>> to=<test2@...>, relay=virtual, delay=372, delays=372/0/0/0,
                        >>>> dsn=2.0.0, status=sent (delivered to maildir)
                        >>>
                        >>>> -rw------- 1 2003 postfix 347 Nov 30 19:28
                        >>>> test2.com/test2/Maildir/new/1291166883.V59Ib97008M906598.sunsaturn.com
                        >>>> -rw------- 1 2003 postfix 347 Nov 30 19:29
                        >>>> test2.com/test2/Maildir/new/1291166943.V59Ib97001M911353.sunsaturn.com
                        >>>
                        >>> Well Postfix asks the operating system nicely by setting its effective
                        >>> uid and gid. If the operating system does not cooperate, you need to
                        >>> find out why.
                        >>>
                        >>> src/virtual/mailbox.c:deliver_mailbox():
                        >>>
                        >>> /* Look up the mailbox owner rights. Defer in case of trouble. */
                        >>> uid_res = mail_addr_find(virtual_uid_maps, state.msg_attr.user,
                        >>> IGNORE_EXTENSION);
                        >>> if (uid_res == 0) { /* error handling */ }
                        >>> if ((n = atol(uid_res)) < var_virt_minimum_uid) { /* error handling */
                        >>> }
                        >>> usr_attr.uid = (uid_t) n;
                        >>>
                        >>> /* Look up the mailbox group rights. Defer in case of trouble. */
                        >>> gid_res = mail_addr_find(virtual_gid_maps, state.msg_attr.user,
                        >>> IGNORE_EXTENSION);
                        >>> if (gid_res == 0) { /* error handling */ }
                        >>> if ((n = atol(gid_res)) <= 0) { /* error handling */ }
                        >>> usr_attr.gid = (gid_t) n;
                        >>>
                        >>> if (msg_verbose)
                        >>> msg_info("%s[%d]: set user_attr: %s, uid = %u, gid = %u",
                        >>> myname, state.level, usr_attr.mailbox,
                        >>> (unsigned) usr_attr.uid, (unsigned) usr_attr.gid);
                        >>>
                        >>> You can configure "virtual -v" in master.cf to see the uid/gid logged.
                        >>>
                        >>> /* Deliver to mailbox or to maildir. */
                        >>> #define LAST_CHAR(s) (s[strlen(s) - 1])
                        >>>
                        >>> if (LAST_CHAR(usr_attr.mailbox) == '/')
                        >>> *statusp = deliver_maildir(state, usr_attr);
                        >>> else
                        >>> *statusp = deliver_mailbox_file(state, usr_attr);
                        >>>
                        >>> src/virtual/mailbox.c:deliver_maildir():
                        >>>
                        >>> set_eugid(usr_attr.uid, usr_attr.gid);
                        >>>
                        >>> /* Creates files, writes data, ... */
                        >>>
                        >>> set_eugid(var_owner_uid, var_owner_gid);
                        >>>
                        >>> --
                        >>> Viktor.
                        >>>
                        >>
                        >
                      • Wietse Venema
                        ... Turn off the SETGID bit in the PARENT directory. Wietse
                        Message 11 of 19 , Dec 1, 2010
                        • 0 Attachment
                          Dan:
                          >
                          > Gid inherits top level directory GID?

                          Turn off the SETGID bit in the PARENT directory.

                          Wietse
                        • Dan
                          There is no setgid bit set. I had to chmod 777 the /website/vuser directory just so that new user creates would work otherwise when it changes uid to some
                          Message 12 of 19 , Dec 1, 2010
                          • 0 Attachment
                            There is no setgid bit set.
                            I had to chmod 777 the /website/vuser directory just so that new user
                            creates would work otherwise when it changes uid to some virtual id such
                            as 2003, it would not be allowed to create anything in the directory to
                            begin with no matter who owned it.

                            Its really problematic because even if end user creates the
                            /website/vuser/test.com directory ahead of time with correct uid and gid
                            like postfix seems to need to work, the uids are an autoincrement field
                            starting at 2002 for each new added user, so you can see how this could be
                            cumbersome quickly.

                            The way postfix is currently working only feasible way to do it would be
                            every virtual user on system share same uid then that parent directory
                            could be
                            owned by that user. In that system, every ftp account, imap, pop3, email
                            account would be owned by same id. I'm almost considering moving to doing
                            it that way just to avoid these issues with postfix, as I'm really trying
                            to see any kind of security issues rising from a parent process forking to
                            the same uid for everything. Only one I can see is if ftp users were not
                            chrooted to their homedirectory they could go around deleting other users
                            files. SInce reason I am sharing same gid across all virtual users to
                            begin with is to chroot ftp users to their home directory, maybe any
                            security risk may be alleviated.

                            A correct solution I think however for postfix would be if mkdir fails
                            with permission denied errors on parent directory, to change uid to root,
                            create directory and change permissions on it.

                            I think I may move to sharing same virtual uid and gid for all virtual
                            users since ftp chroot is only security risk I can see, and if I ever had
                            to move users to a new system and lost permissions on all directories
                            would be cumbersome to chown -R each user to respective uid again.


                            Dan.



                            On Wed, 1 Dec 2010, Wietse Venema wrote:

                            > Dan:
                            >>
                            >> Gid inherits top level directory GID?
                            >
                            > Turn off the SETGID bit in the PARENT directory.
                            >
                            > Wietse
                            >
                          • Jeroen Geilman
                            ... What does namei -m /website/vuser say about it ? 777 is almost always wrong; logically, it just needs to be chown :2001 and chmod 775. ... You should not
                            Message 13 of 19 , Dec 1, 2010
                            • 0 Attachment
                              On 12/01/2010 01:35 PM, Dan wrote:
                              >
                              >
                              > There is no setgid bit set.
                              > I had to chmod 777 the /website/vuser directory just so that new user
                              > creates would work otherwise when it changes uid to some virtual id
                              > such as 2003, it would not be allowed to create anything in the
                              > directory to begin with no matter who owned it.

                              What does

                              namei -m /website/vuser

                              say about it ?

                              777 is almost always wrong; logically, it just needs to be chown :2001
                              and chmod 775.

                              > Its really problematic because even if end user creates the
                              > /website/vuser/test.com directory ahead of time

                              You should not need to do that with vmailboxes.

                              Either the MDA or the IMAP server will create them when needed.

                              > with correct uid and gid like postfix seems to need to work, the uids
                              > are an autoincrement field starting at 2002 for each new added user,
                              > so you can see how this could be cumbersome quickly.
                              >
                              > The way postfix is currently working only feasible way to do it would
                              > be every virtual user on system share same uid then that parent
                              > directory could be owned by that user.

                              That's the usual way to host virtual mailboxes, yes.

                              > In that system, every ftp account, imap, pop3, email account would be
                              > owned by same id.

                              The same physical *system* ID, yes.
                              If this is not what you desire, then using virtual mailbox users makes
                              no sense for you at all.

                              Just use system users, optionally with an invalid shell if you wish to
                              prevent them logging in.

                              > I'm almost considering moving to doing it that way just to avoid these
                              > issues with postfix, as I'm really trying to see any kind of security
                              > issues rising from a parent process forking to the same uid for
                              > everything.

                              Minor to non-existent, as long as you don't go around chmodding stuff to
                              777.

                              > Only one I can see is if ftp users were not chrooted to their
                              > homedirectory they could go around deleting other users files.

                              Use proftpd, it does a virtual chroot.

                              > SInce reason I am sharing same gid across all virtual users to begin
                              > with is to chroot ftp users to their home directory, maybe any
                              > security risk may be alleviated.

                              Yes - use proftpd.

                              >
                              > A correct solution I think however for postfix would be if mkdir fails
                              > with permission denied errors on parent directory, to change uid to
                              > root, create directory and change permissions on it.

                              Absolutely not.
                              Postfix wil never execute commands with root privileges unless
                              specifically configured to do so, and only then in very limited
                              circumstances.

                              Allowing postfix to arbitrarily escalate privileges is fail.

                              > I think I may move to sharing same virtual uid and gid for all virtual
                              > users since ftp chroot is only security risk I can see, and if I ever
                              > had to move users to a new system and lost permissions on all
                              > directories would be cumbersome to chown -R each user to respective
                              > uid again.

                              It sounds like you've been unnecessarily complicating things.
                              Setting up virtual users for multiple services is fairly easy to
                              accomplish, as long as you have some way of making the userdb available
                              to all services.

                              --
                              J.
                            • Dan
                              Thanks for your input, as far as proftpd goes: The distribution file available at the main distribution site and all mirrors has been compromised. The new file
                              Message 14 of 19 , Dec 1, 2010
                              • 0 Attachment
                                Thanks for your input, as far as proftpd goes:

                                The distribution file available at the main distribution site and all
                                mirrors has been compromised.
                                The new file contains a rootkit.

                                Original file:
                                Name: proftpd-1.3.3c.tar.bz2
                                Size: 4166609
                                MD5: 8571bd78874b557e98480ed48e2df1d2
                                SHA256: ea7f02e21f81e6ce79ebde8bbbd334bd269a039ac9137196a35309f791b24db1

                                Compromised file:
                                Name: proftpd-1.3.3c.tar.bz2
                                Size: 4203030
                                MD5: a43df54cc0b16c9e63a1045129d7b144
                                SHA256: d56d6d643534fe618b26807948b3cfe43c02b3f7abf7f4a073778c9c1666d1eb

                                The difference between original and compromised file (rootkit) is
                                attached to this e-mail.


                                Dan.



                                On Wed, 1 Dec 2010, Jeroen Geilman wrote:

                                > On 12/01/2010 01:35 PM, Dan wrote:
                                >>
                                >>
                                >> There is no setgid bit set.
                                >> I had to chmod 777 the /website/vuser directory just so that new user
                                >> creates would work otherwise when it changes uid to some virtual id such as
                                >> 2003, it would not be allowed to create anything in the directory to begin
                                >> with no matter who owned it.
                                >
                                > What does
                                >
                                > namei -m /website/vuser
                                >
                                > say about it ?
                                >
                                > 777 is almost always wrong; logically, it just needs to be chown :2001 and
                                > chmod 775.
                                >
                                >> Its really problematic because even if end user creates the
                                >> /website/vuser/test.com directory ahead of time
                                >
                                > You should not need to do that with vmailboxes.
                                >
                                > Either the MDA or the IMAP server will create them when needed.
                                >
                                >> with correct uid and gid like postfix seems to need to work, the uids are
                                >> an autoincrement field starting at 2002 for each new added user, so you can
                                >> see how this could be cumbersome quickly.
                                >>
                                >> The way postfix is currently working only feasible way to do it would be
                                >> every virtual user on system share same uid then that parent directory
                                >> could be owned by that user.
                                >
                                > That's the usual way to host virtual mailboxes, yes.
                                >
                                >> In that system, every ftp account, imap, pop3, email account would be owned
                                >> by same id.
                                >
                                > The same physical *system* ID, yes.
                                > If this is not what you desire, then using virtual mailbox users makes no
                                > sense for you at all.
                                >
                                > Just use system users, optionally with an invalid shell if you wish to
                                > prevent them logging in.
                                >
                                >> I'm almost considering moving to doing it that way just to avoid these
                                >> issues with postfix, as I'm really trying to see any kind of security
                                >> issues rising from a parent process forking to the same uid for everything.
                                >
                                > Minor to non-existent, as long as you don't go around chmodding stuff to 777.
                                >
                                >> Only one I can see is if ftp users were not chrooted to their homedirectory
                                >> they could go around deleting other users files.
                                >
                                > Use proftpd, it does a virtual chroot.
                                >
                                >> SInce reason I am sharing same gid across all virtual users to begin with
                                >> is to chroot ftp users to their home directory, maybe any security risk may
                                >> be alleviated.
                                >
                                > Yes - use proftpd.
                                >
                                >>
                                >> A correct solution I think however for postfix would be if mkdir fails with
                                >> permission denied errors on parent directory, to change uid to root, create
                                >> directory and change permissions on it.
                                >
                                > Absolutely not.
                                > Postfix wil never execute commands with root privileges unless specifically
                                > configured to do so, and only then in very limited circumstances.
                                >
                                > Allowing postfix to arbitrarily escalate privileges is fail.
                                >
                                >> I think I may move to sharing same virtual uid and gid for all virtual
                                >> users since ftp chroot is only security risk I can see, and if I ever had
                                >> to move users to a new system and lost permissions on all directories would
                                >> be cumbersome to chown -R each user to respective uid again.
                                >
                                > It sounds like you've been unnecessarily complicating things.
                                > Setting up virtual users for multiple services is fairly easy to accomplish,
                                > as long as you have some way of making the userdb available to all services.
                                >
                                > --
                                > J.
                                >
                                >
                              • Jeroen Geilman
                                ... I downloaded the 1.3.3c source and confirmed. Passed it on to the ProFTPd authors and they re looking into it. I will also provide them with the below diff
                                Message 15 of 19 , Dec 1, 2010
                                • 0 Attachment
                                  On 12/01/2010 02:30 PM, Dan wrote:
                                  >
                                  > Thanks for your input, as far as proftpd goes:
                                  >
                                  > The distribution file available at the main distribution site and all
                                  > mirrors has been compromised.
                                  > The new file contains a rootkit.
                                  >

                                  I downloaded the 1.3.3c source and confirmed.
                                  Passed it on to the ProFTPd authors and they're looking into it.
                                  I will also provide them with the below diff if you don't mind.

                                  How did you catch this ?
                                  Is it a FreeBSD checker of some sort, or do you habitually peruse the
                                  entire source of new programs :)

                                  I have used Proftpd many years without it being the victim of such
                                  abuse, though :)

                                  > Original file:
                                  > Name: proftpd-1.3.3c.tar.bz2
                                  > Size: 4166609
                                  > MD5: 8571bd78874b557e98480ed48e2df1d2
                                  > SHA256: ea7f02e21f81e6ce79ebde8bbbd334bd269a039ac9137196a35309f791b24db1
                                  >
                                  > Compromised file:
                                  > Name: proftpd-1.3.3c.tar.bz2
                                  > Size: 4203030
                                  > MD5: a43df54cc0b16c9e63a1045129d7b144
                                  > SHA256: d56d6d643534fe618b26807948b3cfe43c02b3f7abf7f4a073778c9c1666d1eb
                                  >
                                  > The difference between original and compromised file (rootkit) is
                                  > attached to this e-mail.
                                  >
                                  >
                                  > Dan.
                                  >
                                  >
                                  >
                                  > On Wed, 1 Dec 2010, Jeroen Geilman wrote:
                                  >
                                  >> On 12/01/2010 01:35 PM, Dan wrote:
                                  >>>
                                  >>>
                                  >>> There is no setgid bit set.
                                  >>> I had to chmod 777 the /website/vuser directory just so that new
                                  >>> user creates would work otherwise when it changes uid to some
                                  >>> virtual id such as 2003, it would not be allowed to create anything
                                  >>> in the directory to begin with no matter who owned it.
                                  >>
                                  >> What does
                                  >>
                                  >> namei -m /website/vuser
                                  >>
                                  >> say about it ?
                                  >>
                                  >> 777 is almost always wrong; logically, it just needs to be chown
                                  >> :2001 and chmod 775.
                                  >>
                                  >>> Its really problematic because even if end user creates the
                                  >>> /website/vuser/test.com directory ahead of time
                                  >>
                                  >> You should not need to do that with vmailboxes.
                                  >>
                                  >> Either the MDA or the IMAP server will create them when needed.
                                  >>
                                  >>> with correct uid and gid like postfix seems to need to work, the
                                  >>> uids are an autoincrement field starting at 2002 for each new added
                                  >>> user, so you can see how this could be cumbersome quickly.
                                  >>>
                                  >>> The way postfix is currently working only feasible way to do it
                                  >>> would be every virtual user on system share same uid then that
                                  >>> parent directory could be owned by that user.
                                  >>
                                  >> That's the usual way to host virtual mailboxes, yes.
                                  >>
                                  >>> In that system, every ftp account, imap, pop3, email account would
                                  >>> be owned by same id.
                                  >>
                                  >> The same physical *system* ID, yes.
                                  >> If this is not what you desire, then using virtual mailbox users
                                  >> makes no sense for you at all.
                                  >>
                                  >> Just use system users, optionally with an invalid shell if you wish
                                  >> to prevent them logging in.
                                  >>
                                  >>> I'm almost considering moving to doing it that way just to avoid
                                  >>> these issues with postfix, as I'm really trying to see any kind of
                                  >>> security issues rising from a parent process forking to the same uid
                                  >>> for everything.
                                  >>
                                  >> Minor to non-existent, as long as you don't go around chmodding stuff
                                  >> to 777.
                                  >>
                                  >>> Only one I can see is if ftp users were not chrooted to their
                                  >>> homedirectory they could go around deleting other users files.
                                  >>
                                  >> Use proftpd, it does a virtual chroot.
                                  >>
                                  >>> SInce reason I am sharing same gid across all virtual users to begin
                                  >>> with is to chroot ftp users to their home directory, maybe any
                                  >>> security risk may be alleviated.
                                  >>
                                  >> Yes - use proftpd.
                                  >>
                                  >>>
                                  >>> A correct solution I think however for postfix would be if mkdir
                                  >>> fails with permission denied errors on parent directory, to change
                                  >>> uid to root, create directory and change permissions on it.
                                  >>
                                  >> Absolutely not.
                                  >> Postfix wil never execute commands with root privileges unless
                                  >> specifically configured to do so, and only then in very limited
                                  >> circumstances.
                                  >>
                                  >> Allowing postfix to arbitrarily escalate privileges is fail.
                                  >>
                                  >>> I think I may move to sharing same virtual uid and gid for all
                                  >>> virtual users since ftp chroot is only security risk I can see, and
                                  >>> if I ever had to move users to a new system and lost permissions on
                                  >>> all directories would be cumbersome to chown -R each user to
                                  >>> respective uid again.
                                  >>
                                  >> It sounds like you've been unnecessarily complicating things.
                                  >> Setting up virtual users for multiple services is fairly easy to
                                  >> accomplish, as long as you have some way of making the userdb
                                  >> available to all services.
                                  >>
                                  >> --
                                  >> J.
                                  >>
                                  >>


                                  --
                                  J.
                                • Wietse Venema
                                  ... Apparently, FreeBSD copies the GID of a new directory from its parent, even when the parent does not have sticky/setwhatever bits set. bristle# mkdir
                                  Message 16 of 19 , Dec 1, 2010
                                  • 0 Attachment
                                    Dan:
                                    > Gid inherits top level directory GID?

                                    Wietse:
                                    > Turn off the SETGID bit in the PARENT directory.

                                    Dan:
                                    > There is no setgid bit set.

                                    Apparently, FreeBSD copies the GID of a new directory from its
                                    parent, even when the parent does not have sticky/setwhatever
                                    bits set.

                                    bristle# mkdir /var/spool/wietse
                                    bristle# chown wietse /var/spool/wietse
                                    bristle# ls -la /var/spool/wietse
                                    total 4
                                    drwxr-xr-x 2 wietse wheel 512 Dec 1 09:02 .
                                    drwxr-xr-x 12 root wheel 512 Dec 1 09:02 ..
                                    bristle# su wietse -c 'mkdir /var/spool/wietse/test1'
                                    bristle# ls -la /var/spool/wietse
                                    total 6
                                    drwxr-xr-x 3 wietse wheel 512 Dec 1 09:03 .
                                    drwxr-xr-x 12 root wheel 512 Dec 1 09:02 ..
                                    drwxr-xr-x 2 wietse wheel 512 Dec 1 09:03 test1

                                    The test1 directory has group wietse, even though my process
                                    has GID 'wietse'.

                                    Now, I change the parent directory group to 'wietse'
                                    and create a new directory:

                                    bristle# chgrp wietse /var/spool/wietse
                                    bristle# su wietse -c 'mkdir /var/spool/wietse/test2'
                                    bristle# ls -la /var/spool/wietse
                                    total 8
                                    drwxr-xr-x 4 wietse wietse 512 Dec 1 09:03 .
                                    drwxr-xr-x 12 root wheel 512 Dec 1 09:02 ..
                                    drwxr-xr-x 2 wietse wheel 512 Dec 1 09:03 test1
                                    drwxr-xr-x 2 wietse wietse 512 Dec 1 09:03 test2

                                    And test2 has the group of 'wietse'.

                                    bristle# su wietse -c 'chgrp wietse /var/spool/wietse/test1'
                                    bristle# ls -la /var/spool/wietse
                                    total 8
                                    drwxr-xr-x 4 wietse wietse 512 Dec 1 09:03 .
                                    drwxr-xr-x 12 root wheel 512 Dec 1 09:02 ..
                                    drwxr-xr-x 2 wietse wietse 512 Dec 1 09:03 test1
                                    drwxr-xr-x 2 wietse wietse 512 Dec 1 09:03 test2

                                    To force the group, change the group after mkdir. This
                                    does not require switching euid to root.

                                    Wietse

                                    In src/util/make_dirs.c:
                                    if ((ret = mkdir(saved_path, perms)) < 0) {
                                    if (errno != EEXIST)
                                    break;
                                    /* Race condition? */
                                    if ((ret = stat(saved_path, &st)) < 0)
                                    break;
                                    if (!S_ISDIR(st.st_mode)) {
                                    errno = ENOTDIR;
                                    ret = -1;
                                    break;
                                    }
                                    }
                                    ===> if ((ret = chown(saved_path, -1, getegid())) < 0)
                                    ===> break;


                                    Wietse
                                  • lst_hoe02@kwsoft.de
                                    ... They have corrected it, the infected source for download is replaced, but no warning at all for the ones who already downloaded and now using the
                                    Message 17 of 19 , Dec 1, 2010
                                    • 0 Attachment
                                      Zitat von Jeroen Geilman <jeroen@...>:

                                      > On 12/01/2010 02:30 PM, Dan wrote:
                                      >>
                                      >> Thanks for your input, as far as proftpd goes:
                                      >>
                                      >> The distribution file available at the main distribution site and all
                                      >> mirrors has been compromised.
                                      >> The new file contains a rootkit.
                                      >>
                                      >
                                      > I downloaded the 1.3.3c source and confirmed.
                                      > Passed it on to the ProFTPd authors and they're looking into it.
                                      > I will also provide them with the below diff if you don't mind.

                                      They have corrected it, the "infected" source for download is
                                      replaced, but no warning at all for the ones who already downloaded
                                      and now using the trojaned version...

                                      Not very encouraging to use Proftpd.

                                      Regards

                                      Andreas
                                    • Victor Duchovni
                                      ... It seems this applies not just to sub-directories, but also to new files: http://www.manpages.info/freebsd/open.2.html When a new file is created it is
                                      Message 18 of 19 , Dec 1, 2010
                                      • 0 Attachment
                                        On Wed, Dec 01, 2010 at 10:09:30AM -0500, Wietse Venema wrote:

                                        > Apparently, FreeBSD copies the GID of a new directory from its
                                        > parent, even when the parent does not have sticky/setwhatever
                                        > bits set.

                                        It seems this applies not just to sub-directories, but also to new
                                        files:

                                        http://www.manpages.info/freebsd/open.2.html

                                        When a new file is created it is given the group of the directory which
                                        contains it.

                                        http://www.manpages.info/freebsd/mkdir.2.html

                                        The directory's owner ID is set to the process's effective user ID. The
                                        directory's group ID is set to that of the parent directory in which it
                                        is created.

                                        And in http://www.manpages.info/freebsd/mount.2.html, we see:

                                        MNT_SUIDDIR Directories with the SUID bit set chown new files to
                                        their own owner.

                                        without any corresponding mechanism to adjust group ownership inheritance.

                                        The OpenGroup POSIX spec says:

                                        http://www.opengroup.org/onlinepubs/009695399/functions/mkdir.html

                                        The directory's user ID shall be set to the process' effective user
                                        ID. The directory's group ID shall be set to the group ID of the parent
                                        directory or to the effective group ID of the process. Implementations
                                        shall provide a way to initialize the directory's group ID to the
                                        group ID of the parent directory. Implementations may, but need not,
                                        provide an implementation-defined way to initialize the directory's
                                        group ID to the effective group ID of the calling process.

                                        http://www.opengroup.org/onlinepubs/009695399/functions/open.html

                                        O_CREAT
                                        ... the user ID of the file shall be set to the effective user
                                        ID of the process; the group ID of the file shall be set to
                                        the group ID of the file's parent directory or to the effective
                                        group ID of the process; ... Implementations shall provide a
                                        way to initialize the file's group ID to the group ID of the
                                        parent directory. Implementations may, but need not, provide an
                                        implementation-defined way to initialize the file's group ID to the
                                        effective group ID of the calling process.

                                        --
                                        Viktor.
                                      • Voytek Eymont
                                        ... Andreas, ... Subject: [ProFTPD-announce] ProFTPD ftp.proftpd.org compromise From: TJ Saunders Date: Thu, December 2, 2010 10:43
                                        Message 19 of 19 , Dec 2, 2010
                                        • 0 Attachment
                                          On Thu, December 2, 2010 7:20 am, lst_hoe02@... wrote:

                                          > They have corrected it, the "infected" source for download is
                                          > replaced, but no warning at all for the ones who already downloaded and now
                                          > using the trojaned version...
                                          >
                                          > Not very encouraging to use Proftpd.

                                          Andreas,

                                          fwiw, I got this email today:

                                          ---------------------------- Original Message ----------------------------
                                          Subject: [ProFTPD-announce] ProFTPD ftp.proftpd.org compromise
                                          From: "TJ Saunders" <tj@...>
                                          Date: Thu, December 2, 2010 10:43 am
                                          To: proftp-announce@...
                                          Cc: proftp-devel@...
                                          proftp-user@...
                                          --------------------------------------------------------------------------

                                          -----BEGIN PGP SIGNED MESSAGE-----
                                          Hash: SHA1

                                          ProFTPD Compromise Report

                                          On Sunday, the 28th of November 2010 around 20:00 UTC the main
                                          distribution server of the ProFTPD project was compromised. The
                                          attackers most likely used an unpatched security issue in the FTP daemon
                                          to gain access to the server and used their privileges to replace the
                                          source files for ProFTPD 1.3.3c with a version which contained a backdoor.
                                          The unauthorized modification of the source code was noticed by
                                          Daniel Austin and relayed to the ProFTPD project by Jeroen Geilman on
                                          Wednesday, December 1 and fixed shortly afterwards.

                                          The fact that the server acted as the main FTP site for the ProFTPD
                                          project (ftp.proftpd.org) as well as the rsync distribution server
                                          (rsync.proftpd.org) for all ProFTPD mirror servers means that anyone who
                                          downloaded ProFTPD 1.3.3c from one of the official mirrors from 2010-11-28
                                          to 2010-12-02 will most likely be affected by the problem.

                                          The backdoor introduced by the attackers allows unauthenticated users
                                          remote root access to systems which run the maliciously modified version
                                          of the ProFTPD daemon.

                                          Users are strongly advised to check systems running the affected code for
                                          security compromises and compile/run a known good version of the code.
                                          To verify the integrity of the source files, use the GPG signatures
                                          available on the FTP servers as well on the ProFTPD homepage at:

                                          http://www.proftpd.org/md5_pgp.html.
                                          ---snip-----


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