Re: Custom post login scripting variables via ID command
On 2022-09-26 07:03, Aki Tuomi wrote:
On 22/09/2022 23:05 EEST hi@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-.
Usage:
1 ID ("x-originating-ip" "1.2.3.4" "x-originating-port" "3133"...)
Aki
Thanks so much for clarifying this.
Zakaria.
Re: Custom post login scripting variables via ID command
> On 22/09/2022 23:05 EEST hi@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-.
Usage:
1 ID ("x-originating-ip" "1.2.3.4" "x-originating-port" "3133"...)
Aki
Re: Custom post login scripting variables via ID command
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.
Re: Custom post login scripting variables via ID command
> 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).
Custom post login scripting variables via ID command
Hi there, 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 hope the dev team to consider this and if anyone have a workaround or an idea with I can start to patch a workaround myself, please let me know as it would be very much appreciated. With thanks. Zakaria.
