On Dec 16, 2009, at 11:40 PM, Lukas Haase wrote: > # 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 :)
Really? Having uid field used multiple times doesn't work in v1.1+. Maybe v1.0 code worked differently. But at least you should be aware of that if you upgrade Dovecot the above settings will break.. Unfortunately there's currently no easy way to do that. >>> 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. It has a UID and a bunch of GID numbers stored in the 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. No, kernel changes the UID, GID and supplementary groups only when userspace processes explicitly tell it to (or implicitly when setuid/setgid binary is executed). Kernel knows nothing about /etc/passwd, /etc/group or username <-> UID number mappings, or even usernames or group names at all. So what happens is that dovecot master process forks a new imap process that starts up as root, then the imap process figures out what permissions it should be running as and executes the appropriate syscalls to get itself to that state.
