[Dovecot] Why dovecot does not want to read my acl file?
Hi,
Simple Scenario: Shared namespace and a specific UNIX group should have access to it. System is Debian lenny (stable).
# cat /etc/dovecot/dovecot.conf [...] namespace public { separator = . prefix = Shared. location = maildir:/var/mail/shared } mail_executable = /usr/local/sbin/dovecot-imap-fix.sh mail_drop_priv_before_exec = no #just to make sure [...]
# dpkg -l | grep dovecot ii dovecot-common 1:1.0.15-2.3+lenny1 secure mail server that ii dovecot-imapd 1:1.0.15-2.3+lenny1 secure IMAP server that
# cat /usr/local/sbin/dovecot-imap-fix.sh
#!/bin/sh
cat /var/mail/shared/.Office/dovecot-acl > /tmp/dovecot-$USER
env >> /tmp/dovecot-$USER
ACL_GROUPS=groups $USER | tr ' ' ','
export ACL_GROUPS
exec /usr/lib/dovecot/imap $*
# ls -la -R /var/mail/shared/ # (cut the .,.. in output) /var/mail/shared/: total 28 drwxrwx--- 5 root office 4096 Dec 15 15:53 .Office drwxr-xr-x 2 root root 4096 Dec 14 16:55 cur -rw-r--r-- 1 root root 23 Dec 15 07:46 dovecot-acl -rw-r--r-- 1 root root 0 Dec 15 07:42 dovecot-shared drwxr-xr-x 2 root root 4096 Dec 14 16:55 new drwxr-xr-x 2 root root 4096 Dec 14 16:55 tmp
/var/mail/shared/.Office: total 24 drwxrwx--- 2 root office 4096 Dec 15 09:53 cur -rw-r--r-- 1 root root 52 Dec 15 15:53 dovecot-acl -rw-rw---- 1 root office 0 Dec 15 07:42 dovecot-shared drwxrwx--- 2 root office 4096 Dec 15 09:53 new drwxrwx--- 2 root office 4096 Dec 15 09:53 tmp
# id peter uid=1000(peter) gid=100(users) groups=51683(office),25783(ssh_users),100(users) #
Now I log in as peter but I my client (latest TB 2) does not display the office folder. In the log it claimes that it is not able to open the acl file what really can NOT be true:
Dec 15 15:56:05 mail dovecot: IMAP(peter): acl vfile: no access to file /var/mail/shared/.Office/dovecot-acl
I tried:
- su peter: Access no problem!
- ps aux: The process is running as peter
- As you can see I have debugging code in my dovecot-imap-fix.sh which successfully prints out the content of the ACL file to /tmp/user-peter
I can't image that, it seems as if it is not true.
By the way: As soon as I change the mail_executable to /usr/local/sbin/dovecot-imap-fix.sh I get this message and have absolutely no clue why:
# /etc/init.d/dovecot restart Restarting IMAP/POP3 mail server: dovecotid: dump-capability: No such user . #
Which dump-capability? Which user?
Does anybody have an idea what could be wrong here?
Thank you very much, Luke
Charles Marcus schrieb:
On 12/15/2009, Lukas Haase (lukashaase@gmx.at) wrote:
# cat /etc/dovecot/dovecot.conf
No, output of dovecot -n please...
Sorry:
# 1.0.15: /etc/dovecot/dovecot.conf log_timestamp: %Y-%m-%d %H:%M:%S protocols: imaps managesieve ssl_ca_file: /etc/ssl/services/mail/sub.class1.server.ca.crt ssl_cert_file: /etc/ssl/services/mail/mail.crt ssl_key_file: /etc/ssl/services/mail/mail.key login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(managesieve): /usr/lib/dovecot/managesieve-login mail_privileged_group: mail mail_location: maildir:~/Maildir mail_executable(default): /usr/local/sbin/dovecot-imap-fix.sh mail_executable(imap): /usr/local/sbin/dovecot-imap-fix.sh mail_executable(managesieve): /usr/local/sbin/managesieve-nsfix.sh mail_plugins(default): acl mail_plugins(imap): acl mail_plugins(managesieve): mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(managesieve): /usr/lib/dovecot/modules/managesieve sieve_storage(default): sieve_storage(imap): sieve_storage(managesieve): ~/sieve sieve(default): sieve(imap): sieve(managesieve): ~/.dovecot.sieve namespace: type: private separator: . prefix: INBOX. inbox: yes namespace: type: public separator: . prefix: Public. location: maildir:/var/mail/public:CONTROL=~/Maildir/public:INDEX=~/Maildir/public namespace: type: public separator: . prefix: Shared. location: maildir:/var/mail/shared auth default: passdb: driver: passwd-file args: /etc/dovecot/passwd passdb: driver: ldap args: /etc/dovecot/dovecot-ldap.conf userdb: driver: prefetch userdb: driver: ldap args: /etc/dovecot/dovecot-ldap.conf plugin: sieve_global_path: /etc/dovecot/default.sieve acl: vfile
Regards, Luke
On Wed, 2009-12-16 at 00:24 +0900, Lukas Haase wrote:
mail_drop_priv_before_exec = no #just to make sure
"no" means it starts the process as root as root. I guess you meant to use "yes".
# cat /usr/local/sbin/dovecot-imap-fix.sh #!/bin/sh cat /var/mail/shared/.Office/dovecot-acl > /tmp/dovecot-$USER
It reads the file while running as root.
ACL_GROUPS=
groups $USER | tr ' ' ','export ACL_GROUPS
I don't think ACL_GROUPS is supported by Dovecot v1.0.
By the way: As soon as I change the mail_executable to /usr/local/sbin/dovecot-imap-fix.sh I get this message and have absolutely no clue why:
# /etc/init.d/dovecot restart Restarting IMAP/POP3 mail server: dovecotid: dump-capability: No such user . #
Which dump-capability? Which user?
It's because at startup Dovecot executes imap mail_executable as "dump-capability" user to find out what IMAP capabilities enabled plugins add. In your script you should probably check that if $USER=dump-capability, don't do anything special.
Hi Timo,
Thank zou for your reply!
Timo Sirainen schrieb:
On Wed, 2009-12-16 at 00:24 +0900, Lukas Haase wrote:
mail_drop_priv_before_exec = no #just to make sure
"no" means it starts the process as root as root. I guess you meant to use "yes".
I know but I tried both in order to see if it is maybe because of this entry.
Anyway, the ACL could not be read in either way...
[...]
ACL_GROUPS=
groups $USER | tr ' ' ','export ACL_GROUPSI don't think ACL_GROUPS is supported by Dovecot v1.0.
:( :(
But nevertheless, let us just forget about the ACL_GROUPS, I would be interested why the ACL file could not be read.
Further things I forgot:
- In the homedirs the scenario is the same. The one user that has access to the files is the user peter itself and there I got no errors about reading the ACL files
- Reading succeeds when I set the directory (.Office) to 755
- For testing I wrote authenticated lrwstiek into the dovecot-acl which means that the problem can not depend on the ACL itself.
I just do not understand. The process runs as user peter and complains that it is unable to open the ACL file. But the file is definitively readable for user peter, as I checked with su. Also the error is gone when I set the directory to 755 ... that sounds really strange for me...
By the way: As soon as I change the mail_executable to /usr/local/sbin/dovecot-imap-fix.sh I get this message and have absolutely no clue why:
# /etc/init.d/dovecot restart Restarting IMAP/POP3 mail server: dovecotid: dump-capability: No such user . #
Which dump-capability? Which user?
It's because at startup Dovecot executes imap mail_executable as "dump-capability" user to find out what IMAP capabilities enabled plugins add. In your script you should probably check that if $USER=dump-capability, don't do anything special.
Hmm, I do not fully understand. You can see my whole script in the OP ... there is not done anything special, isnt it?
Best regards, Luke
Hi again,
I have some additional notes.
Lukas Haase wrote:
Timo Sirainen schrieb:
[...]
ACL_GROUPS=
groups $USER | tr ' ' ','export ACL_GROUPSI don't think ACL_GROUPS is supported by Dovecot v1.0.
I removed that part again and instead of using group=office I just enumerate all possible users in the ACL file:
anyone user=peter lrwstiek user=user1 lrwstiek user=user2 lrwstiek user=user3 lrwstiek user=user4 lrwstiek
Further things I forgot:
- In the homedirs the scenario is the same. The one user that has access to the files is the user peter itself and there I got no errors about reading the ACL files
- Reading succeeds when I set the directory (.Office) to 755
- For testing I wrote authenticated lrwstiek into the dovecot-acl which means that the problem can not depend on the ACL itself.
In the meantime I also tried something else: I added the user "dovecot" to the "office" group:
# id dovecot uid=107(dovecot) gid=106(dovecot) groups=51683(office),106(dovecot)
Now I can read the file too as user dovecot (su dovecot).
But I still get the message:
Dec 16 07:53:51 mail dovecot: IMAP(peter): acl vfile: no access to file /var/mail/shared/.Office/dovecot-acl
I just do not understand. The process runs as user peter and complains that it is unable to open the ACL file. But the file is definitively readable for user peter, as I checked with su. Also the error is gone when I set the directory to 755 ... that sounds really strange for me...
[...] It's because at startup Dovecot executes imap mail_executable as "dump-capability" user to find out what IMAP capabilities enabled plugins add. In your script you should probably check that if $USER=dump-capability, don't do anything special.
Hmm, I do not fully understand. You can see my whole script in the OP ... there is not done anything special, isnt it?
Thank you, non I understand! The message is because that user does not exist. When I add an if-clause it works.
Regards, Luke
On Wed, 2009-12-16 at 15:56 +0900, Lukas Haase wrote:
In the meantime I also tried something else: I added the user "dovecot" to the "office" group:
# id dovecot uid=107(dovecot) gid=106(dovecot) groups=51683(office),106(dovecot)
Now I can read the file too as user dovecot (su dovecot).
Don't do that. dovecot is an internal user for internal purposes. It shouldn't have access to anything on your filesystem. http://wiki.dovecot.org/UserIds
Dec 16 07:53:51 mail dovecot: IMAP(peter): acl vfile: no access to file /var/mail/shared/.Office/dovecot-acl
I just do not understand. The process runs as user peter and complains that it is unable to open the ACL file. But the file is definitively readable for user peter, as I checked with su. Also the error is gone when I set the directory to 755 ... that sounds really strange for me...
The difference is that su gives you access to all of the user's groups, while in your setup your userdb probably is returning only one of them (and probably not the one you expect).
drwxrwx--- 5 root office 4096 Dec 15 15:53 .Office
Why are your files and directories owned by root, instead of peter?
On Wed, 2009-12-16 at 14:36 -0500, Timo Sirainen wrote:
drwxrwx--- 5 root office 4096 Dec 15 15:53 .Office
Why are your files and directories owned by root, instead of peter?
Oh right, kind of stupid question. I already forgot we were talking about shared mailboxes. :)
But anyway, the problem has to do with userdb not returning those UNIX groups that you expect.
Perhaps you should just set:
mail_access_groups = office
Hello,
Timo Sirainen wrote:
On Wed, 2009-12-16 at 14:36 -0500, Timo Sirainen wrote:
drwxrwx--- 5 root office 4096 Dec 15 15:53 .Office Why are your files and directories owned by root, instead of peter?
Oh right, kind of stupid question. I already forgot we were talking about shared mailboxes. :)
But anyway, the problem has to do with userdb not returning those UNIX groups that you expect.
Oh, ok I think there is a point which I do not understand. What has the userdb to do with UNIX rights? As far as I understood from the wiki there are two levels:
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)
Internal access system based on the ACLs plugin. I disabled this part temporarily.
I am working with UNIX systems for over 10 years now and until now I always debugged permission errors that way. It is the first time that "a user belongs to a group but does not belong to the group" ... what I want to day with that: A user belongs to a group or not, that is part of the operating systems and must not be different through different application, mustn't it? That must be the same over the whole operating system and until now, this was always the case.
So far I also do not understand what the userdb has to do with that. The userdb is just for *internal* users of the application (dovecot) and has nothing to do with the access system from the operating system or the system users/groups.
Perhaps you should just set:
mail_access_groups = office
In fact I do not want to do this because the plan is to have an arbitrary amount of groups on the system with different members, permissions and folders.
Regards, Luke
On Thu, 2009-12-17 at 10:55 +0900, Lukas Haase wrote:
But anyway, the problem has to do with userdb not returning those UNIX groups that you expect.
Oh, ok I think there is a point which I do not understand. What has the userdb to do with UNIX rights? As far as I understood from the wiki there are two levels:
- 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
The question is what fields does LDAP return? 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.
So far I also do not understand what the userdb has to do with that. The userdb is just for *internal* users of the application (dovecot)
Exactly.
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.
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
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.
Hi again,
Timo Sirainen wrote:
On Dec 16, 2009, at 11:40 PM, Lukas Haase wrote: [...] 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.
Auh, does not sound good. I think in this case it is not an option.
What about the "not easy" ways? I guess it includes at least self compiling?
[...] 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.
Ah, thank you very much now, I understand.
Regards, Luke
participants (4)
-
Charles Marcus
-
Lukas Haase
-
Peter Mairhofer
-
Timo Sirainen