Custom post login scripting variables via ID command

[hi at zakaria.website]

On 2022-09-26 07:03, Aki Tuomi wrote:
>> 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

Thanks so much for clarifying this.

Zakaria.