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

Use "authorized_submit_users" to exclude all users in a Unix Group

Expand Messages
  • JLP
    Originally, I was trying to make smtpd_sender_restrictions work, but Noel Jones (thanks again!) clued-me into the config-option authorized_submit_users
    Message 1 of 8 , May 30, 2012
    • 0 Attachment
      Originally, I was trying to make "smtpd_sender_restrictions" work, but
      Noel Jones (thanks again!) clued-me into the config-option
      "authorized_submit_users" when using the sendmail (or derivative)
      binaries. I tried unsuccessfully making some form of unix:group.byname
      work like these options:
      authorized_submit_users=!unix:group.byname, static:all
      authorized_submit_users=!unix:group.byname=badUnixGroup, static:all

      Short of creating a cronjob-script to regularly re/create a HASH file of
      disallowed users in the Unix group, is there something obvious I am missing?
    • /dev/rob0
      ... You missed the postconf(5) manual, specifically the description of authorized_submit_users. Negation can apply to a /file/name but not to a type:table
      Message 2 of 8 , May 30, 2012
      • 0 Attachment
        On Wed, May 30, 2012 at 05:05:16PM -0400, JLP wrote:
        > Originally, I was trying to make "smtpd_sender_restrictions"
        > work, but Noel Jones (thanks again!) clued-me into the
        > config-option "authorized_submit_users" when using the sendmail
        > (or derivative) binaries. I tried unsuccessfully making some
        > form of unix:group.byname work like these options:
        > authorized_submit_users=!unix:group.byname, static:all
        > authorized_submit_users=!unix:group.byname=badUnixGroup, static:all
        >
        > Short of creating a cronjob-script to regularly re/create a HASH
        > file of disallowed users in the Unix group, is there something
        > obvious I am missing?

        You missed the postconf(5) manual, specifically the description of
        authorized_submit_users. Negation can apply to a /file/name but not
        to a type:table lookup.

        http://www.postfix.org/postconf.5.html#authorized_submit_users

        You'll want to make your list, e.g., /etc/postfix/nosend, and then
        negate the list:

        authorized_submit_users=!/etc/postfix/nosend, static:all

        Two bits of general advice:

        You might want to save a link in your browser to your
        $html_directory. Everything is in there; no need to guess. I don't
        see any reference to your "unix:group.byname=badUnixGroup" syntax,
        therefore I'd assume that it is not implemented.

        Having untrusted shell users on a machine is a bad idea. If you
        cannot trust them to honor your mail policies, can you trust them to
        refrain from other nefarious activities?
        --
        http://rob0.nodns4.us/ -- system administration and consulting
        Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
      • JLP
        I did review the http://www.postfix.org/postconf.5.html#authorized_submit_users page and it mentions that patterns can be negated, here are the relevant
        Message 3 of 8 , May 31, 2012
        • 0 Attachment
          I did review the
          http://www.postfix.org/postconf.5.html#authorized_submit_users page and
          it mentions that patterns can be negated, here are the relevant strings
          of the docs I thought applicable to this case.

          Specify a list of user names, "/file/name" or "type:table" patterns ...
          Specify "!pattern" to exclude a user name from the list.
          The form "!/file/name" is supported only in Postfix version 2.4 and
          later.

          If patterns aren't supported, thank you for setting me straight, I was
          just hoping to avoid building a script to regularly re/create the nosend
          file. Should I submit a bug report for a documentation change to make
          this point more clearly?

          As for the "authorized_submit_users=!unix:group.byname=badUnixGroup"
          syntax, I found an OLD example in a mailing list, not the manpage-docs,
          I was trying to show what I was attempting.

          There are no 'untrusted' users, but in this case we need this
          functionality for software-testing accounts which has in the past
          repeatedly spammed a large group of people when 3rd-party utilities that
          call mutt/sendmail/etc when certain error conditions occurred. We
          thought about disabling Postfix entirely for all users, but in this
          case, we would miss out on other more necessary alerts from other
          users/utilities on that box.





          On 5/30/2012 7:24 PM, /dev/rob0 wrote:
          > On Wed, May 30, 2012 at 05:05:16PM -0400, JLP wrote:
          >> Originally, I was trying to make "smtpd_sender_restrictions"
          >> work, but Noel Jones (thanks again!) clued-me into the
          >> config-option "authorized_submit_users" when using the sendmail
          >> (or derivative) binaries. I tried unsuccessfully making some
          >> form of unix:group.byname work like these options:
          >> authorized_submit_users=!unix:group.byname, static:all
          >> authorized_submit_users=!unix:group.byname=badUnixGroup, static:all
          >>
          >> Short of creating a cronjob-script to regularly re/create a HASH
          >> file of disallowed users in the Unix group, is there something
          >> obvious I am missing?
          > You missed the postconf(5) manual, specifically the description of
          > authorized_submit_users. Negation can apply to a /file/name but not
          > to a type:table lookup.
          >
          > http://www.postfix.org/postconf.5.html#authorized_submit_users
          >
          > You'll want to make your list, e.g., /etc/postfix/nosend, and then
          > negate the list:
          >
          > authorized_submit_users=!/etc/postfix/nosend, static:all
          >
          > Two bits of general advice:
          >
          > You might want to save a link in your browser to your
          > $html_directory. Everything is in there; no need to guess. I don't
          > see any reference to your "unix:group.byname=badUnixGroup" syntax,
          > therefore I'd assume that it is not implemented.
          >
          > Having untrusted shell users on a machine is a bad idea. If you
          > cannot trust them to honor your mail policies, can you trust them to
          > refrain from other nefarious activities?
        • /dev/rob0
          Please don t top-post your replies here. It makes the conversation much harder to follow. ... Actually I think your interpretation of the negation was correct,
          Message 4 of 8 , May 31, 2012
          • 0 Attachment
            Please don't top-post your replies here. It makes the conversation
            much harder to follow.

            On Thu, May 31, 2012 at 10:35:25AM -0400, JLP wrote:
            > On 5/30/2012 7:24 PM, /dev/rob0 wrote:
            > >On Wed, May 30, 2012 at 05:05:16PM -0400, JLP wrote:
            > >>Originally, I was trying to make "smtpd_sender_restrictions"
            > >>work, but Noel Jones (thanks again!) clued-me into the
            > >>config-option "authorized_submit_users" when using the sendmail
            > >>(or derivative) binaries. I tried unsuccessfully making some
            > >>form of unix:group.byname work like these options:
            > >> authorized_submit_users=!unix:group.byname, static:all
            > >> authorized_submit_users=!unix:group.byname=badUnixGroup, static:all
            > >>
            > >>Short of creating a cronjob-script to regularly re/create a HASH
            > >>file of disallowed users in the Unix group, is there something
            > >>obvious I am missing?
            > >You missed the postconf(5) manual, specifically the description of
            > >authorized_submit_users. Negation can apply to a /file/name but not
            > >to a type:table lookup.
            > >
            > >http://www.postfix.org/postconf.5.html#authorized_submit_users

            > I did review the
            > http://www.postfix.org/postconf.5.html#authorized_submit_users page
            > and it mentions that patterns can be negated, here are the relevant
            > strings of the docs I thought applicable to this case.
            >
            > Specify a list of user names, "/file/name" or "type:table" patterns ...
            > Specify "!pattern" to exclude a user name from the list.
            > The form "!/file/name" is supported only in Postfix version 2.4
            > and later.
            >
            > If patterns aren't supported, thank you for setting me straight, I
            > was just hoping to avoid building a script to regularly re/create the
            > nosend file. Should I submit a bug report for a documentation change
            > to make this point more clearly?

            Actually I think your interpretation of the negation was correct,
            mine was wrong.

            Where you were in error was the fact that the search performed was
            for the username, not for the group name. unix:group.byname will
            return a value if the group name is found.

            There is no "authorized_submit_groups" feature. That would have done
            what you wanted to do.

            > As for the "authorized_submit_users=!unix:group.byname=badUnixGroup"
            > syntax, I found an OLD example in a mailing list, not the
            > manpage-docs, I was trying to show what I was attempting.

            Right. My point being that the person who posted that was guessing.
            There is no shortage of false and misleading "information" on the
            web; not so, in the documentation. We do have our occasional
            misunderstandings, as you did confusing a username search for a
            groupname search, and as I did with the "!pattern" negation, but
            careful rereading usually clears things up.
            --
            http://rob0.nodns4.us/ -- system administration and consulting
            Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
          • Octavio
            Hello I having problems with some emails that arrives 2 or 7 times to their destination I have check the log and each time they generate a different ID, other
            Message 5 of 8 , May 31, 2012
            • 0 Attachment
              Hello

              I having problems with some emails that arrives 2 or 7 times to their destination I have check the log and each time they generate a different ID, other issue that probably is related is this error I get in my log

              May 30 12:23:23 mail postfix/local[22794]: 1023A80188: to=<her@...>, relay=local, delay=140, delays=119/0/0/20, dsn=4.2.0, status=deferred (cannot update mailbox /var/mail/her.mailbox for user her.mailbox. unable to lock for exclusive access: Resource temporarily unavailable)

              Thanks

              Octavio

            • Viktor Dukhovni
              ... No in fact Postfix these days supports negation of table lookups in match lists. However, the lookup key remains the same, and clearly
              Message 6 of 8 , May 31, 2012
              • 0 Attachment
                On Wed, May 30, 2012 at 06:24:31PM -0500, /dev/rob0 wrote:

                > > I tried unsuccessfully making some
                > > form of unix:group.byname work like these options:
                > > authorized_submit_users=!unix:group.byname, static:all
                > > authorized_submit_users=!unix:group.byname=badUnixGroup, static:all
                > >
                > > Short of creating a cronjob-script to regularly re/create a HASH
                > > file of disallowed users in the Unix group, is there something
                > > obvious I am missing?
                >
                > You missed the postconf(5) manual, specifically the description of
                > authorized_submit_users. Negation can apply to a /file/name but not
                > to a type:table lookup.

                No in fact Postfix these days supports negation of table lookups
                in match lists. However, the lookup key remains the same, and
                clearly authorized_submit_users searching any given table with the
                user name as the lookup key, which cannot do what the OP wants.
                With tables in match lists the result of the lookup is ignored,
                the only thing that matters is whether the key is present in the
                table or not.

                So the "!unix:group.byname=foo" syntax is a desperate attempt to
                clutch at straws and invent new syntax. Don't do that with Postfix,
                it doesn't have fancy undocumented syntax. There is nothing
                special about the "=" character in a table name, so the OP was
                trying to use "unix:group.byname=foo" table, which does not exist,
                in fact there is not even a "unix:group.byname" table, rather per:

                http://www.postfix.org/DATABASE_README.html#types

                there are only these:

                unix (read-only)
                A limited way to query the UNIX authentication database. The
                following tables are implemented:

                unix:passwd.byname
                The table is the UNIX password database. The key is a login
                name. The result is a password file entry in passwd(5)
                format.

                unix:group.byname
                The table is the UNIX group database. The key is a group
                name. The result is a group file entry in group(5) format.

                Don't use a tcptable or a socketmap (I forget which recent Postfix
                versions have this) to check the user's group, since this is fragile,
                if the table service is down no local mail can be queued, and
                sendmail/postdrop are designed to queue mail under adverse conditions,
                even when the rest of Postfix is not running. So only tables that
                persist on disk are appropriate in this context.

                --
                Viktor.
              • Banyan He
                Hi Octavio, Did you check the file permission of /var/mail/her.mailbox to postfix? Was the resource down? Was the file system issue? I think you better check
                Message 7 of 8 , Jun 1, 2012
                • 0 Attachment
                  Hi Octavio,

                  Did you check the file permission of /var/mail/her.mailbox to postfix? Was the resource down? Was the file system issue? I think you better check out /var/log/messages or dmsgs as well.

                  Best regards,
                  ------------
                  Banyan He
                  Blog: http://www.rootong.com
                  Email: banyan@...

                  On 2012-05-31 11:48 PM, Octavio wrote:
                  Hello

                  I having problems with some emails that arrives 2 or 7 times to their destination I have check the log and each time they generate a different ID, other issue that probably is related is this error I get in my log

                  May 30 12:23:23 mail postfix/local[22794]: 1023A80188: to=<her@...>, relay=local, delay=140, delays=119/0/0/20, dsn=4.2.0, status=deferred (cannot update mailbox /var/mail/her.mailbox for user her.mailbox. unable to lock for exclusive access: Resource temporarily unavailable)

                  Thanks

                  Octavio

                • Octavio
                  Hi Banyan after a couple of tries the email goes in the mailbox drwxrwsr-x 2 root mail   (/var/spool/mail/) Octavio ... De: Banyan He
                  Message 8 of 8 , Jun 4, 2012
                  • 0 Attachment
                    Hi Banyan

                    after a couple of tries the email goes in the mailbox
                    drwxrwsr-x 2 root mail   (/var/spool/mail/)


                    Octavio
                    --- El vie, 6/1/12, Banyan He <banyan@...> escribió:

                    De: Banyan He <banyan@...>
                    Asunto: Re: Repeated emails
                    A: "Octavio" <octaviomaiden@...>
                    Cc: "postfix-users@..." <postfix-users@...>
                    Fecha: viernes, 1 de junio de 2012, 11:40 pm

                    Hi Octavio,

                    Did you check the file permission of /var/mail/her.mailbox to postfix? Was the resource down? Was the file system issue? I think you better check out /var/log/messages or dmsgs as well.

                    Best regards,
                    ------------
                    Banyan He
                    Blog: http://www.rootong.com
                    Email: banyan@...

                    On 2012-05-31 11:48 PM, Octavio wrote:
                    Hello

                    I having problems with some emails that arrives 2 or 7 times to their destination I have check the log and each time they generate a different ID, other issue that probably is related is this error I get in my log

                    May 30 12:23:23 mail postfix/local[22794]: 1023A80188: to=<her@...>, relay=local, delay=140, delays=119/0/0/20, dsn=4.2.0, status=deferred (cannot update mailbox /var/mail/her.mailbox for user her.mailbox. unable to lock for exclusive access: Resource temporarily unavailable)

                    Thanks

                    Octavio

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