[Dovecot] ldap: LDAP attribute used multiple times. This is currently unsupported
Lukas Haase
lukashaase at gmx.at
Wed Feb 9 00:12:01 EET 2011
Dear Timo,
Thank you for your advice!
Am 08.02.2011 18:35, schrieb Timo Sirainen:
> On 8.2.2011, at 17.23, Lukas Haase wrote:
>>[...]
>>
>> I know, but the message is somehow "weird" since it says it is
>> *currently* unsupported. However, it seems to me that it is not
>> supported any more. Is this true? Is there a reason for this?
>
> I'm pretty sure it never worked. I think in v1.0 it simply ignored
> the first uid=user. So you could probably just remove that.
Unfortunately not. I am really sure it worked in v1.0. For example:
# id luke
uid=1000(luke) gid=100(users)
groups=51683(family),25783(ssh_users),63315(projects),19580(multimedia),1019(data),51684(friends),100(users)
So luke's *primary* group is "users" but he is also member of the other
groups (like "family").
An IMAP folder in my shared namespace has permissions as follows:
# ls -la /var/mail/shared
[...]
drwxrwx--- 5 root family 4096 Feb 8 22:53 .Family
[...]
So the folder "Family" in the shared namespace is *not* accessible in
the *default* configuration since the directory is not accessible by the
group "users" but only by the group "family". And in the default
configuration the groups are ignored by dovecot (except the primary group).
In Debian Lenny (dovecot 1.xx) I set "uid=system_user" in the
"user_attrs" setting of my ldap config. According to the Wiki, this
should read out the primary groups of the user contained in the LDAP
field "uid". And this worked: I could access the folder.
Now I upgraded to Debian sequeeze (dovecot 1.2) and I get the mentioned
error message. So I am somehow sure that it actually worked and was not
just ignored.
Nevertheless, is there a way to overcome this issue? Can dovecot just
read out the group membership from the "user" field of "pass_attrs"?
Another obvious solution would be to define a manual scheme with a
manual attribute "uid_dovecot" and copy the value of "uid". But this
seems to me like a using a sledgehammer method since it provides
unnecessary redundancy in the LDAP tree (where the increased complexity
might cause problems and inconsistencies) and requires defined a manual
LDAP scheme.
Any solution would be greatly appreciated!
Best regads,
Luke
More information about the dovecot
mailing list