[Dovecot] Why dovecot does not want to read my acl file?

[Lukas Haase]

Hello Timo,

once again thanks for your reply!

Timo Sirainen wrote:
> On Thu, 2009-12-17 at 10:55 +0900, Lukas Haase wrote:
> [...]
>> * UNIX rights. The mailboxes need to just have the correct *UNIX* 
>> permission in order to access the files in the needed way (read or 
>> write). So IMO this could also be achieved with, say, POSIX ACLs (setfacl)
> 
> Right. The issue has to do with what UNIX rights Dovecot sets for the
> process. In a previous mail you said you used:
> 
>>    userdb:
>>      driver: ldap
>>      args: /etc/dovecot/dovecot-ldap.conf

Exactly.

> The question is what fields does LDAP return?

Euhm, I use LDAP as passdb and prefetch as user db. Authentication is
done with bind.

The attributes I get from the LDAP server are (as far as I understand):

pass_attrs =
uid=user,userPassword=password,homeDirectory=userdb_home,uidNumber=userdb_uid,gidNumber=userdb_gid

> When you're using ldap,
> Dovecot doesn't directly use /etc/group or NSS equivalent to figure out
> what groups a users belong to. If you want Dovecot to do that, you need
> to return system_user=<username> field from userdb.

Hmm, ok, I see. I just tried it:

# when using authentication via LDAP + prefetch
pass_attrs =
uid=user,userPassword=password,homeDirectory=userdb_home,uidNumber=userdb_uid,gidNumber=userdb_gid,uid=userdb_system_user

# when using optional authentication via file + LDAP
# I do this that each user can define an optional password
# only valid for E-Mail in /etc/dovecot/passwd which is
# different from the "important" system password
user_attrs = homeDirectory=home,uidNumber=uid,gidNumber=gid,uid=system_user

And indeed! It seems to work now :)

> [...]
>> and has 
>> nothing to do with the access system from the operating system or the 
>> system users/groups.
> 
> But you want Dovecot to interact with operating system's users/groups,
> so you need to tell Dovecot how to do that.

But still, IMHO this can not be the scope of an application but the
operating system. Each process is a user and a group assigned. And this 
information is directly in the process structure, i.e. in the *kernel*. 
And AFAIK the secondary groups are also in this process structure.

That means: If I execute a program the *kernel* sets the UID and the GID 
of the process as well as groups the user belongs to. I still do not 
understand that a userspace program modifies this kernel structure. This 
would be the same as starting the process as specified user and 
ignoring/changing the GID.


Regards,
Luke