Lua Auth

[Mark Moseley]

On Fri, Dec 22, 2017 at 5:18 AM, <aki.tuomi at dovecot.fi> wrote:

>
> > On December 22, 2017 at 8:20 AM Mark Moseley <moseleymark at gmail.com>
> wrote:
> >
> >
> > On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote:
> >
> > >
> > > > On December 22, 2017 at 6:43 AM Mark Moseley <moseleymark at gmail.com>
> > > wrote:
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2) Is there an appropriate way to return data with spaces in it (or
> > > > > presumably other non-alphanum chars. My quota name had a space in
> it,
> > > > > which
> > > > > somehow got interpreted as 'yes' , i.e.:
> > > > >
> > > > > imap: Error: Failed to initialize quota: Invalid quota root quota:
> > > Unknown
> > > > > quota backend: yes
> > > > >
> > > > > I simply changed the space to an underscore as a workaround, but
> I'm
> > > > > curious if there's a better way. I tried various quoting without
> > > success.
> > > > > Didn't try escaping yet.
> > > > >
> > > > >
> > > > > 2) Instead of string, return a key value table. you can have
> spaces in
> > > > > values.
> > > > >
> > > > >
> > > > >
> > > > Does this work for auth_passdb_lookup too, or just
> auth_userdb_lookup?
> > > I've
> > > > been returning a table with auth_userdb_lookup just fine. But when I
> try
> > > > using it with passdb (and despite being very very sure that a
> 'password'
> > > > key exists in the table I'm returning from auth_passdb_lookup() --
> I'm
> > > > logging it one line above the return), the passdb auth fails with
> this
> > > log
> > > > entry:
> > > >
> > > > Dec 21 23:29:22 auth-worker(7779): Info:
> > > > lua(test1 at test.com,10.20.103.32,<dSvLQuZg+uIKFGcg>):
> > > > No password returned (and no nopassword)
> > > >
> > > > I guess it's not seeing the password key in the table I'm returning.
> If I
> > > > return a concat'd string ("password=... user=...") from
> > > > auth_passdb_lookup(), it works just fine.
> > > >
> > > > I was also curious if there's a way to pass info between
> > > auth_userdb_lookup
> > > > and auth_passdb_lookup. I was trying to use a table with
> > > > auth_passdb_lookup() so I could take advantage of prefetch and
> thought
> > > that
> > > > if auth_passdb_lookup didn't take a table, I could stash data away
> and
> > > then
> > > > un-stash it in auth_userdb_lookup
> > > >
> > > > Thanks!
> > > >
> > > >
> > >
> > > Yeah, this is a bug we have fixed =)
> > >
> > > https://github.com/dovecot/core/commit/c86575ac9776d0995355d03719c82e
> > > 7ceac802e6#diff-83374eeaee91d90e848390ba3c7b264a
> > >
> > >
> >
> > I'm on rc1, so I appear to already have that git commit (as part of rc1).
> >
> > # /usr/sbin/dovecot  --version
> > 2.3.0.rc1 (12aba5948)
> >
> > For testing this, I tried replacing my passdb lookup with this:
> >
> > function auth_passdb_lookup(req)
> >         passdb_table = {}
> >         passdb_table[ 'password' ] = 'test'
> >         passdb_table[ 'user' ] = 'test1 at test.com'
> >
> >         return dovecot.auth.PASSDB_RESULT_OK, passdb_table
> > end
> >
> > and still get:
> >
> > Dec 22 01:17:17 auth-worker(9711): Info:
> > lua(test1 at test.com,10.20.103.32,<f2O5xOdgFoYKFGcg>):
> > No password returned (and no nopassword)
> >
> > Replacing that return statement with this:
> >
> > return dovecot.auth.PASSDB_RESULT_OK, 'password=test user=test1 at test.com
> '
> >
> > authenticates successfully.
>
> Fixed in https://github.com/dovecot/core/commit/
> e5fb6b3b7d4e79475b451823ea6c0a02955ba06b
>
>
>
Works like a charm now, thanks!

As a matter of 'best practices', in my current iteration of Lua auth, I
moved all my lookups to passdb (thus yesterday's emails to the list), so
that it could be used with prefetch. Belatedly realizing that LMTP doesn't
touch passdb, I rewrote the userdb lookup to call the same passdb lookup
(which only happens for non-passdb/prefetch things) and then it copies the
return table (but strips the 'userdb_' prefix). It's all working currently.
BUT, does that sound sane? Or is there some gotcha I'm heading towards
(yes, I realize the question is a bit vague -- just looking for very
general "No, don't do that").

I'm curious too if I can set vars in the passdb lookup and then access then
in userdb. Or is it random which auth-worker will handle the userdb lookup,
relative to which one handled the passdb lookup? I tried dropping things in
the req.userdb table in the passdb phase, but it was unset during the
userdb phase.