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.
