On M 27 Apr, 2009, at 23:23 , Giuliano Gavazzi wrote:

For me it's not a big deal, as was trying this only to give a
different layout to users' mailboxes.

but it would be a big deal if I wanted to create domain specific
public mailboxes. In order to allow extra parameters passed by the client (like in this
case the domain name) to survive for subsequent use, perhaps there
should be a username_format for all passdb (and userdb) methods, like
the is for passwd-file. One could then let auth_username_format alone
and preserve the %d variable for subsequent use. If I did not want %d
to be used at all, I would not specify it in the client configuration
from the start...

The documentation would have to be quite clear though, as
auth_username_format seems more specific to authentication/ authorisation, while username_format would seem a global one, while,
as it is now, auth_username_format rewrites globally the username, and
username_format is specific to the authentication/authorization where
it is allowed and defined.

Giuliano

On W 29 Apr, 2009, at 22:21 , Giuliano Gavazzi wrote:

I am trying to patch the source so that the %d expansion variable
uses original_username (instead of user I suppose) of auth_request,
but I cannot find where this expansion is done.. Pointers?

Thanks Giuliano

I thought it was in auth_request_get_var_expand_table, and changed thus:

//GG tab[2].value = strchr(auth_request->user, '@'); tab[2].value = strchr(auth_request->original_username,
'@'); //GG test to keep domain

but this makes no difference (well, not in the expansion for
mail_location).

I found other places where var_expand_table is set (easy, as you
always use tab as a local variable), but as they were not passed
auth_request it was not possible to get the original_username. I think I can see a reason behind this: ignoring the domain passed
when authenticating means that the domain part has not been checked
and thus its use unwarranted. In the case of system users this would
pose no threat, but for virtual users it might, in principle, allow an
unauthorised access to other maildirs.

Giuliano

On T 30 Apr, 2009, at 18:31 , Timo Sirainen wrote:

On Wed, 2009-04-29 at 22:21 +0200, Giuliano Gavazzi wrote:

...

I am trying to patch the source so that the %d expansion variable
uses original_username (instead of user I suppose) of auth_request, but I cannot find where this expansion is done.. Pointers?

Well, the problem is .. %d expansion is done from the whole username. And its life starts in dovecot-auth, but most of the expansions
outside auth settings is done by master process. So you'd probably have to
make dovecot-auth change the username back to original_username after authentication is finished.

What passdb are you using anyway? Maybe this could be done more
easily.

sorry, I mentioned it en passant in a previous reply, so it passed
unnoticed: system passwd. Also, as I said, there is a slight chance that using an unchecked
domain in a maildir location would permit access to someone else
maildir (for virtual users only though).

Thanks

Giuliano

On Wed, 2009-05-20 at 08:55 -0700, RoyK wrote:

I see the same happen on Ubuntu Linux 8.04LTS, Dovecot 1.0.5. Config is given below. %u is expanded on the password_query, but not with the user_query, according to the mysql query log.

Show your password_query.

RoyK wrote:

These are the two queries being executed

181 Query SELECT username as user, password, domain FROM users WHERE username = 'test' and domain = 'mydomain.com' 181 Query SELECT 'maildir:/var/spool/dovecot//test' as mail, uid, gid, domain FROM users WHERE username = 'test' and domain = ''

And here is the stuff from the config

user_query = SELECT 'maildir:/var/spool/dovecot/%d/%n' as mail, uid, gid, domain FROM users WHERE username = '%n' and domain = '%d' password_query = SELECT username as user, password, domain FROM users WHERE username = '%n' and domain = '%d'

roy

View this message in context: http://www.nabble.com/-d-does-not-expand-to-domain-tp23258935p23639781.html Sent from the Dovecot mailing list archive at Nabble.com.