Custom post login scripting variables via ID command

[Aki Tuomi]

> On 22/09/2022 23:05 EEST hi at zakaria.website wrote:
> 
>  
> On 2022-09-22 16:24, Brendan Braybrook wrote:
> >> I wonder if dovecot would consider this feature request. In post login
> >> scripting, given USER, IP, LOCAL_IP, and userdb lookup fields, are 
> >> only
> >> available, I want to push additional variables from web mail to 
> >> dovecot
> >> using ID commands yet I looked at the source in imap-login-cmd-id.c 
> >> and
> >> script-login.c it seems to be possible while I'm not an expert in C 
> >> and
> >> IMAP standards and not sure if its something would break the 
> >> standards.
> > 
> > i think this can do what you need. this little bit of config:
> > 
> > # trusted networks that can use the extended ID data we use for auth 
> > now
> > login_trusted_networks = 192.168.0.10
> > # retain these so we can log client names (when provided)
> > imap_id_retain=yes
> > 
> > makes connections from 192.168.0.10 trusted so that the imap ID fields
> > get passed around during the auth/userdb processes.
> > 
> > if you then use the new lua scripting for the userdb lookup
> > (https://doc.dovecot.org/configuration_manual/authentication/lua_based_authentication/#authentication-lua-based-authentication),
> > you can get the value of the imap client id via auth_request#client_id
> > 
> > here's a little snippet to get you started:
> > ---
> > 
> > package.path = package.path .. ";/usr/share/lua/5.1/?.lua"
> > package.cpath = package.cpath .. 
> > ";/usr/lib/x86_64-linux-gnu/lua/5.1/?.so"
> > require 'lfs'
> > 
> > function auth_userdb_lookup(req)
> >   dovecot.i_info("dovecot-auth.lua: authdb client_id = [" ..
> > req.client_id .. "]")
> >   ret = {}
> >   ret.client_id = req.client_id
> >   // ret.homedir = ...etc...
> >   // need the rest of the userdb lookup bits
> >   return dovecot.auth.USERDB_RESULT_OK, ret
> > end
> > 
> > ---
> > 
> > you'll want to update that to return everything you need from the 
> > userdb
> > lookup, but the data returned by userdb should get pushed to your
> > post_login script. you should see $CLIENT_ID as an env variable with 
> > the
> > example code above.
> > 
> > also note: make sure your post login script explicitly calls bash and
> > don't get burned by /bin/sh pointing at dash (as happened to me 
> > recently
> > - otherwise some environment variables might not show up with dash).
> 
> Thanks so much for this, very much appreciated.
> 
> Anyhow, for anyone looking for quicker and easier solution, I was able 
> to overwrite x_connected_ip using id command thats returning the value 
> of LOCAL_IP, since I wanted to block some client apps from using my IMAP 
> server yet your reference to login trusted networks, doubted me if I've 
> done things right. Probably I need to make sure restricted client apps 
> cant just perform id command and overwrites LOCAL_IP and bypass the 
> restriction likewise my webmail and I hope this is what trusted login 
> networks is for, and as per doc, it seems to be like so.

Hi!

You should use the login_trusted_networks to enable passing variables over ID command. You can then use the supported ways there to set original IP and such without needing to touch the source code.

Currently supported ID values are:
x-originating-ip, x-originating-port, x-connected-ip, x-connected-port, x-proxy-ttl, x-session-id, x-session-ext-id, x-forward-<some_variable_name>.

Usage:

1 ID ("x-originating-ip" "1.2.3.4" "x-originating-port" "3133"...)

Aki