[Dovecot] System users, mbox format and global ACLs
I need some help here... ;-)
I'm experimenting with global ACLs, but just fail to understand very
basic behaviors.
So, before digging into the source code, I would really be delighted
if someone could immediately point a mistake I'm making and miserably
overlooking.
The output of dovecot -n is provided at the end of this email.
Just in case, conforming to the suggestion made in http://wiki.dovecot.org/ACL
, I've specified a CONTROL directory; but I get a similar behavior
without it.
As far as the acl plugin is concerned, I've just specified a directory
for global ACLs; whether that directory is populated or not doesn't
seem to have an impact on the observed behavior.
Here's the structure of the test user's home directory:
total 0
drwx------ 4 testuser people 136 26 jui 13:52 .
drwxr-xr-x 3 root admin 102 19 mai 16:56 ..
drwxr-xr-x 4 testuser people 136 28 jui 17:09 _mailboxes
drwxr-xr-x 2 testuser people 68 28 jui 17:07 _mboxesctrl
./_mailboxes:
total 96
drwxr-xr-x 4 testuser people 136 28 jui 17:09 .
drwx------ 4 testuser people 136 26 jui 13:52 ..
drwx------ 3 testuser people 102 19 mai 17:02 .imap
-rw------- 1 testuser people 48685 25 jui 16:58 inbox
./_mailboxes/.imap:
total 0
drwx------ 3 testuser people 102 19 mai 17:02 .
drwxr-xr-x 4 testuser people 136 28 jui 17:09 ..
drwx------ 5 testuser people 170 23 jui 18:02 INBOX
./_mailboxes/.imap/INBOX:
total 88
drwx------ 5 testuser people 170 23 jui 18:02 .
drwx------ 3 testuser people 102 19 mai 17:02 ..
-rw------- 1 testuser people 1376 23 jui 18:02 dovecot.index
-rw------- 1 testuser people 26624 28 jui 10:23 dovecot.index.cache
-rw-rw-rw- 1 testuser people 10284 25 jui 17:57 dovecot.index.log
./_mboxesctrl:
total 0
drwxr-xr-x 2 testuser people 68 28 jui 17:07 .
drwx------ 4 testuser people 136 26 jui 13:52 ..
I've tried various combinations of permissions and ownership, again
without any obvious influence.
The manual creation of directory ~/_mboxesctrl/.imap doesn't seem to
be more helpful.
So, let's go to the heart of my "problem":
# telnet 127.0.0.1 imap
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
AUTH=PLAIN] Dovecot ready.
a1 login testuser ******
a1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID
ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE
CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC
ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH] Logged in
a2 list "" *
* LIST (\NoInferiors \UnMarked) "/" "dovecot-acl-list"
* LIST (\HasNoChildren \UnMarked) "/" "INBOX"
a2 OK List completed.
a3 logout
* BYE Logging out
a3 OK Logout completed.
Connection closed by foreign host.
And indeed, a file named "dovecot-acl-list" has now been created under
the _mailboxes directory:
./_mailboxes:
total 96
drwxr-xr-x 5 testuser people 170 28 jui 17:11 .
drwx------ 4 testuser people 136 26 jui 13:52 ..
drwx------ 3 testuser people 102 19 mai 17:02 .imap
-rw-r--r-- 1 testuser people 0 28 jui 17:11 dovecot-acl-list
-rw------- 1 testuser people 48685 25 jui 16:58 inbox
This is the only file to have been created consecutively to the telnet
session.
Is such a file supposed to be created there?
If yes, why? I would have tended to believe that it is more a server
internal matter than a name having to appear in the namespace.
More generally, is such a file supposed to be created at all? After
all, the configuration doesn't explicitely mention per-mailbox ACLs at
all...
Anyway, this is what gets written in mail.log for the whole telnet
session:
dovecot[82305]: auth(default): new auth connection: pid=82374
dovecot[82305]: auth(default): client in: AUTH 1 PLAIN service=imap
secured lip=127.0.0.1 rip=127.0.0.1 lport=143 rport=49879 resp=<hidden>
dovecot[82305]: auth-worker(default): pam(testuser,127.0.0.1): lookup
service=imap
dovecot[82305]: auth-worker(default): pam(testuser,127.0.0.1): #1/1
style=1 msg=Password:
dovecot[82305]: auth(default): client out: OK 1 user=testuser
dovecot[82305]: auth(default): master in: REQUEST 8 82327 1
dovecot[82305]: auth(default): passwd(testuser,127.0.0.1): lookup
dovecot[82305]: auth(default): master out: USER 8 testuser
system_groups_user=testuser uid=2001 gid=2001 home=/Volumes/ALMbpSpare/
People/a/testuser
dovecot[82305]: imap-login: Login: user=<testuser>, method=PLAIN,
rip=127.0.0.1, lip=127.0.0.1, secured
dovecot[82305]: IMAP(testuser): Loading modules from directory: /usr/
local/dovecot-1.2.rc7/lib/dovecot/imap
dovecot[82305]: IMAP(testuser): Module loaded: /usr/local/
dovecot-1.2.rc7/lib/dovecot/imap/lib01_acl_plugin.so
dovecot[82305]: IMAP(testuser): Effective uid=2001, gid=2001, home=/
Volumes/ALMbpSpare/People/a/testuser
dovecot[82305]: IMAP(testuser): acl: No acl_shared_dict setting -
shared mailbox listing is disabled
dovecot[82305]: IMAP(testuser): mbox: data=~/_mailboxes:INBOX=~/
_mailboxes/inbox:CONTROL=~/_mboxesctrl
dovecot[82305]: IMAP(testuser): fs: root=/Volumes/ALMbpSpare/People/a/
testuser/_mailboxes, index=, control=/Volumes/ALMbpSpare/People/a/
testuser/_mboxesctrl, inbox=/Volumes/ALMbpSpare/People/a/testuser/
_mailboxes/inbox
dovecot[82305]: IMAP(testuser): acl: initializing backend with data:
vfile:/usr/local/etc/dovecot-acls
dovecot[82305]: IMAP(testuser): acl: acl username = testuser
dovecot[82305]: IMAP(testuser): acl: owner = 1
dovecot[82305]: IMAP(testuser): acl vfile: Global ACL directory: /usr/
local/etc/dovecot-acls
dovecot[82305]: IMAP(testuser): acl vfile: file /usr/local/etc/
dovecot-acls//.DEFAULT not found
dovecot[82305]: IMAP(testuser): Namespace : Using permissions from /
Volumes/ALMbpSpare/People/a/testuser/_mailboxes: mode=0755 gid=-1
dovecot[82305]: IMAP(testuser): acl vfile: file /usr/local/etc/
dovecot-acls/.temp.ALMbp.local.82375.f9efcb24711711fb not found
dovecot[82305]: IMAP(testuser): acl vfile: file /Volumes/ALMbpSpare/
People/a/testuser/_mboxesctrl/.imap/.temp.ALMbp.local.
82375.f9efcb24711711fb/dovecot-acl not found
dovecot[82305]: IMAP(testuser): acl vfile: file /usr/local/etc/
dovecot-acls/INBOX not found
dovecot[82305]: IMAP(testuser): acl vfile: file /Volumes/ALMbpSpare/
People/a/testuser/_mboxesctrl/.imap/INBOX/dovecot-acl not found
dovecot[82305]: IMAP(testuser): acl vfile: file /usr/local/etc/
dovecot-acls/dovecot-acl-list not found
dovecot[82305]: IMAP(testuser): acl vfile: file /Volumes/ALMbpSpare/
People/a/testuser/_mboxesctrl/.imap/dovecot-acl-list/dovecot-acl not
found
dovecot[82305]: IMAP(testuser): Disconnected: Logged out bytes=23/431
Why does the server seem to expect to find a temp file under ~/ _mboxesctrl/.imap? As well as, more surprisingly, under /usr/local/etc/ dovecot-acls?
In a word: Some bad configuration of mine? Or some bug somewhere? Or do I just don't understand ACLs as implemented by dovecot?
TIA, Axel
# 1.2.rc7: /usr/local/etc/dovecot.conf # OS: Darwin 9.7.0 i386 protocols: pop3 imap ssl: no disable_plaintext_auth: no login_dir: /usr/local/var/run/dovecot/login login_executable(default): /usr/local/dovecot-1.2.rc7/libexec/dovecot/ imap-login login_executable(imap): /usr/local/dovecot-1.2.rc7/libexec/dovecot/ imap-login login_executable(pop3): /usr/local/dovecot-1.2.rc7/libexec/dovecot/ pop3-login first_valid_uid: 2001 mail_location: mbox:~/_mailboxes:INBOX=~/_mailboxes/inbox:CONTROL=~/ _mboxesctrl mail_debug: yes mbox_read_locks: flock mbox_write_locks: flock dotlock mail_executable(default): /usr/local/dovecot-1.2.rc7/libexec/dovecot/ imap mail_executable(imap): /usr/local/dovecot-1.2.rc7/libexec/dovecot/imap mail_executable(pop3): /usr/local/dovecot-1.2.rc7/libexec/dovecot/pop3 mail_plugins(default): acl mail_plugins(imap): acl mail_plugins(pop3): mail_plugin_dir(default): /usr/local/dovecot-1.2.rc7/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/dovecot-1.2.rc7/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/dovecot-1.2.rc7/lib/dovecot/pop3 pop3_lock_session(default): no pop3_lock_session(imap): no pop3_lock_session(pop3): yes pop3_uidl_format(default): %08Xu%08Xv pop3_uidl_format(imap): %08Xu%08Xv pop3_uidl_format(pop3): %08Xv%08Xu auth default: debug: yes passdb: driver: pam args: * userdb: driver: passwd plugin: acl: vfile:/usr/local/etc/dovecot-acls
Le 28 juin 09 à 18:26, Axel Luttgens a écrit :
[...] Is such a file supposed to be created there? If yes, why? I would have tended to believe that it is more a server
internal matter than a name having to appear in the namespace. [...]
Re-reading the above, I thought it could be worth to somewhat elaborate.
Once the file ~/_mailboxes/dovecot-acl-list has been created, it in
fact becomes a SELECTable mailbox!
And it is impossible to get rid of it, as it is immediately re-created
upon a LIST command:
# telnet 127.0.0.1 imap
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
AUTH=PLAIN] Dovecot ready.
a1 login testuser ******
a1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID
ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE
CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC
ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH] Logged in
a2 list "" %
* LIST (\NoInferiors \UnMarked) "/" "dovecot-acl-list"
* LIST (\NoInferiors \UnMarked) "/" "Sent"
* LIST (\HasNoChildren \UnMarked) "/" "INBOX"
a2 OK List completed.
a3 delete dovecot-acl-list
a3 OK Delete completed.
a4 list "" %
* LIST (\NoInferiors \UnMarked) "/" "dovecot-acl-list"
* LIST (\NoInferiors \UnMarked) "/" "Sent"
* LIST (\HasNoChildren \UnMarked) "/" "INBOX"
a4 OK List completed.
a5 select dovecot-acl-list
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)]
Flags permitted.
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1] UIDs valid
* OK [UIDNEXT 1] Predicted next UID
* OK [HIGHESTMODSEQ 1]
a5 OK [READ-WRITE] Select completed.
a6 logout
* BYE Logging out
a6 OK Logout completed.
Connection closed by foreign host.
Axel
I had hoped no one would ever try to use ACLs with mbox format.. I don't think I want to try to make it work.
And indeed, a file named "dovecot-acl-list" has now been created under
the _mailboxes directory: .. Is such a file supposed to be created there?
It's created to mailbox root directory. With all formats except mbox this is fine. It can't be created to control directory, because it's supposed to be shared and different users may have different control directories.
But I suppose with mbox it's better to create it to control dir rather than have it show up as a mailbox or use some other weird location for it.
http://hg.dovecot.org/dovecot-1.2/rev/f3c6cabae3af http://hg.dovecot.org/dovecot-1.2/rev/4c8175452173
Why does the server seem to expect to find a temp file under ~/ _mboxesctrl/.imap? As well as, more surprisingly, under /usr/local/etc/ dovecot-acls?
Because it just created a .temp. file and then thinks it's a mailbox. This fixes it: http://hg.dovecot.org/dovecot-1.2/rev/bf4f542ec6df
And then finally also a caching fix: http://hg.dovecot.org/dovecot-1.2/rev/5d1a52e8d320
Le 8 juil. 09 à 04:54, Timo Sirainen a écrit :
On Tue, 2009-07-07 at 22:53 -0400, Timo Sirainen wrote:
I had hoped no one would ever try to use ACLs with mbox format.. I
don't think I want to try to make it work.Oops, forgot to delete the second sentence. I did it anyway after some internal struggling. :)
Really sorry for having occasioned so much trouble...
As a miserable attempt to diminish my culpability: since various pages
in the wiki explicitely mention the use of ACLs with the mbox format
and the CONTROL setting, I first thought in all innocence that I was
doing something wrong, then tended to believe that some slight glitch
had been introduced with 1.2, and then...
That said, I really think it's a great thing to keep the mbox format
on a par with the other ones[1].
Even if, of course, it comes with its limitations.
So, once again, many thanks. Axel
[1] As Mark would say: "Compatibility, compatibility...". ;-)
Le 8 juil. 09 à 04:53, Timo Sirainen a écrit :
[...] http://hg.dovecot.org/dovecot-1.2/rev/f3c6cabae3af http://hg.dovecot.org/dovecot-1.2/rev/4c8175452173 [...] [...]http://hg.dovecot.org/dovecot-1.2/rev/bf4f542ec6df [...] http://hg.dovecot.org/dovecot-1.2/rev/5d1a52e8d320
Ouch!
After having spent several days on that one, I guessed it was far
beyond me; but I still was too optimistic. ;-)
Thanks, Axel
participants (2)
-
Axel Luttgens
-
Timo Sirainen