Re: [Dovecot] ACLs - creating new top level folders
Hello,
Am 22.05.2013 18:35, schrieb Timo Sirainen:
With v2.2.2: http://hg.dovecot.org/dovecot-2.2/rev/714dfc072d60
Doesn't work for public namespaces though.
Thanks for this hint. It seems I should upgrade our server in near future.
Public namespaces do not have this problem. While I was looking for a
solution for my problem, I also played with them instead of a shared
namespace. With this config snippet:
namespace public {
separator = /
prefix = "Shared\ Folders/"
location =
maildir:/home/mail01/shared/Maildir:INDEX=/srv/dovecot/index/shared:CONTROL=/srv/dovecot/control/shared
subscriptions = no
list = children
}
This leads to this folder layout:
/home/mail01/shared/Maildir/.project1/cur
/home/mail01/shared/Maildir/.project1/new
/home/mail01/shared/Maildir/.project1/tmp
/home/mail01/shared/Maildir/.project1/dovecot-acl
/home/mail01/shared/Maildir/.project1./cur
/home/mail01/shared/Maildir/.project1./new
/home/mail01/shared/Maildir/.project1./tmp
/home/mail01/shared/Maildir/.project1./dovecot-acl
/home/mail01/shared/Maildir/.project1./maildirfolder
/home/mail01/shared/Maildir/.project1.j/cur
/home/mail01/shared/Maildir/.project1.j/new
/home/mail01/shared/Maildir/.project1.j/tmp
/home/mail01/shared/Maildir/.project1.j/dovecot-acl
/home/mail01/shared/Maildir/.project1.j/maildirfolder
Now I have a parent folder, where I can place the dovecot-acl file:
/home/mail01/shared/Maildir/.project1/
Probably because this folder is not handled as INBOX like with private
and shared namespaces. It would be a little tricky to put new mail in
these kind of folders with Dovecot LDA. But it could be done. The next
question would be, where to put sieve scripts? The main reason, why I
don't like this solution, is the fear, that this can be problematic from
a performance view. Access permissions of public namespaces are not
listed in the file "shared-mailboxes". What if the folder
"/home/mail01/shared/Maildir" contains some thousand subfolders? Is this
a problem, because every imap process have to open all dovecot-acl files
in these directories?
Ingo Rogalsky
Re: [Dovecot] user login on behalf of another user
Hello, Am 06.02.2012 16:05, schrieb Timo Sirainen: Master user doesn't necessarily have access to all users' mailboxes. In the passdb lookup you can decide if this master user is allowed to be this destination user. For example if you used passdb checkpassword, you could look at USER and MASTER_USER environment variables to figure out if this combination should be allowed or not. The checkpassword script can also do the actual authentication via PAM (I'd think there's a way to call it somehow). Thank you. I got an idea, how I could configure this. Ingo
Re: [Dovecot] user login on behalf of another user
Am 05.02.2012 18:14, schrieb Sven Hartge: Isn't this the kind of scenario shared folders were made for? Yes, of course. Although I didn't called it shared folders in my original post, I had this in mind, when I wrote that ACLs would be the better solution. But for historical reasons we are already in the situation having these kind of accounts. And I don't want to reconfigure about 100 clients now. This would need more time than I want spend now. Ingo
[Dovecot] user login on behalf of another user
Hello, we are searching for a possibility to configure a user login on behalf of another user with a PAM backend. This reminds to the behavior of a master user. But a master user can access the mailboxes of all users. We need this more restricted. Example: User "user1" and "user2" shall get access to the mailbox "info". We define the accounts "info~user1" and "info~user2" with the same home directory like "info". Until now, we use a passwd-file backend. With this setup we can simply copy the password hash from "user1" to "info~user1" and from "user2" to "info~user2". But we intend to change the passdb backend from a flat file to PAM for authentication against Active Directory. This seems to be simple with pam_krb5. But then we can't simply copy password hashes anymore. Is their another possibility for configuring this? Surely the preferable alternative would be the use of ACLs to give acccess to other users mailboxes. But we started this setup with Dovecot 1.0 or 1.1. And with these versions, ACLs weren't available. And now we have too much accounts and clients, which are configured this way and can't change this for the short term. The passdb/userdb file from the above example looks like this: info:!:501:501:Info:/home/mail01/info:: info~user1:PASSWORD_USER1:501:501:Info:/home/mail01/info:: \ userdb_mail=maildir:~/Maildir: \ INDEX=/srv/dovecot/index/info: \ CONTROL=/srv/dovecot/control/info info~user2:PASSWORD_USER2:501:501:Info:/home/mail01/info:: \ userdb_mail=maildir:~/Maildir: \ INDEX=/srv/dovecot/index/info: \ CONTROL=/srv/dovecot/control/info user1:PASSWORD_USER1:501:501:Info:/home/mail01/user1:: user2:PASSWORD_USER2:501:501:Info:/home/mail01/user2:: Ingo Rogalsky
