[Dovecot] Problems with masteruser
I have very strange problem with masteruser. See two logs below:
# telnet localhost 143 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Welcome to our post server! x login nevorotin password x OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS ACL RIGHTS=texk] Logged in x list "" "*"
- LIST (\HasNoChildren) "/" "INBOX" x OK List completed. x getacl INBOX
- ACL "INBOX" "nevorotin" lrwstipekxacd x OK Getacl completed.
All work perfectly. And then I log in throw masteruser:
# telnet localhost 143 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Welcome to our post server! x login nevorotin*master masterpassword x OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS ACL RIGHTS=texk] Logged in x list "" "*"
- LIST (\Unmarked) "/" "INBOX" x OK List completed. x getacl INBOX x NO [NONEXISTENT] Mailbox doesn't exist: INBOX
I've turned on debug logging, but there aren't any errors. I only see that masteruser succesfully logged in as nevorotin. How can I make a masteruser login to user account exactly the same as simple user login? Now it don't work at all [?]
I use 1.2.10 version of dovecot.
Quoting ????????? ????? nevorotin@gmail.com:
I have very strange problem with masteruser. See two logs below:
I can't help, but I can add my observations... Using dovecot 1.2.11 and master users, I noticed that if I login with to a user (real-user) using the master user (master-user), then the mailbox listing shows all non-acl mailboxes fine, but for acl-controlled mailboxes it shows those for which "master-user" has access, not those for which "real-user" has access.
This really freaked me out the first time I logged in and a shared folder showed up when it shouldn't have. I thought I had shared it with everyone! But I was able to verify that a real login to "real-user" doesn't see the shared folder, while a master login to "real-user" does see it. So it is the master user login that is messing up the acl checks.
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
It's look like a big bug. As I understang there shouldn't be any different between logging in with masteruser and normal log in. But in my system I can't use masteruser at all due to IMAP errors.
2010/4/9 Eric Rostetter rostetter@mail.utexas.edu
Quoting ????????? ????? nevorotin@gmail.com:
I have very strange problem with masteruser. See two logs below:
I can't help, but I can add my observations... Using dovecot 1.2.11 and master users, I noticed that if I login with to a user (real-user) using the master user (master-user), then the mailbox listing shows all non-acl mailboxes fine, but for acl-controlled mailboxes it shows those for which "master-user" has access, not those for which "real-user" has access.
This really freaked me out the first time I logged in and a shared folder showed up when it shouldn't have. I thought I had shared it with everyone! But I was able to verify that a real login to "real-user" doesn't see the shared folder, while a master login to "real-user" does see it. So it is the master user login that is messing up the acl checks.
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
Quoting Неворотин Вадим nevorotin@gmail.com:
It's look like a big bug. As I understang there shouldn't be any different between logging in with masteruser and normal log in. But in my system I can't use masteruser at all due to IMAP errors.
It works for me, with two exceptions:
- The acl issue I mentioned.
- It doesn't work right in my "webmail" for anything but the e-mail part, since the webmail retains the user as "master*real" instead of just real. So it does log me in and show me the mail, but everything else (preferences, filters, address book, etc) don't work right. The webmail has "hooks" which should allow me to fix this, but I've not had time to figure that out yet.
So basically, it works for me, which just two little annoyances (one is dovecot specific, the other is actually my webmail and not dovecot).
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
Well, the main idea of master users is to able to log in as normal user with master password. So IMAP client shoudn't know at all that it work with masteruser password. And IMAP process must be exactly the same. If you can find difference between login*master and login - then there is a bug in master users implementation. I see a big difference))))
2010/4/9 Eric Rostetter rostetter@mail.utexas.edu
Quoting Неворотин Вадим nevorotin@gmail.com:
It's look like a big bug. As I understang there shouldn't be any different
between logging in with masteruser and normal log in. But in my system I can't use masteruser at all due to IMAP errors.
It works for me, with two exceptions:
- The acl issue I mentioned.
- It doesn't work right in my "webmail" for anything but the e-mail part, since the webmail retains the user as "master*real" instead of just real. So it does log me in and show me the mail, but everything else (preferences, filters, address book, etc) don't work right. The webmail has "hooks" which should allow me to fix this, but I've not had time to figure that out yet.
So basically, it works for me, which just two little annoyances (one is dovecot specific, the other is actually my webmail and not dovecot).
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
On Fri, 2010-04-09 at 20:53 +0400, Неворотин Вадим wrote:
Well, the main idea of master users is to able to log in as normal user with master password. So IMAP client shoudn't know at all that it work with masteruser password. And IMAP process must be exactly the same. If you can find difference between login*master and login - then there is a bug in master users implementation. I see a big difference))))
It's not a bug, it's an intentional feature. What you're requesting is a different feature. You could try if having your userdb return master_user=%u field would make it work the way you want.
Hmm[?] For what can I use masterusers, if I even can't read with masteruser user's mails from INBOX? And where can I read about masterusers in that way. I really can't understand for what there is masterusers if they can't do anything)))
2010/4/16 Timo Sirainen tss@iki.fi
On Fri, 2010-04-09 at 20:53 +0400, Неворотин Вадим wrote:
Well, the main idea of master users is to able to log in as normal user with master password. So IMAP client shoudn't know at all that it work with masteruser password. And IMAP process must be exactly the same. If you can find difference between login*master and login - then there is a bug in master users implementation. I see a big difference))))
It's not a bug, it's an intentional feature. What you're requesting is a different feature. You could try if having your userdb return master_user=%u field would make it work the way you want.
On Fri, 2010-04-16 at 15:30 +0400, Неворотин Вадим wrote:
Hmm[?] For what can I use masterusers, if I even can't read with masteruser user's mails from INBOX? And where can I read about masterusers in that way. I really can't understand for what there is masterusers if they can't do anything)))
The feature was originally implemented for a voicemail feature. There would be a "voicemail" master user that would have permission to write new mails to users' "voicemail" mailbox, but nothing else.
You could have a similar "spam" master user that only has access to users' "Spam" mailbox (for training spam bayesian or whatever).
Anyway, did you try my suggestion on how to make it work the way you wanted? If it doesn't work yet, I can change the code to make it work:
You could try if having your userdb return master_user=%u field would make it work the way you want.
I've add
$ENV{'MASTER_USER'} = $ENV{'USER'};
to my postlogin-imap script, and it looks like that all is working, thank you!!! I'll test it next week, but as I see ACL and base operations work, so I think that all other works too))
But what does it mean when I return in master_user field current user's name?))) As I understand it increase masteruser's rights to full control of user's mailbox. But if I return in master_user not a current user name, but something else?))) What master_user field control?))) (Sorry, I can't find any information about this feature[?])
2010/4/16 Timo Sirainen tss@iki.fi
On Fri, 2010-04-16 at 15:30 +0400, Неворотин Вадим wrote:
Hmm[?] For what can I use masterusers, if I even can't read with masteruser user's mails from INBOX? And where can I read about masterusers in that way. I really can't understand for what there is masterusers if they can't do anything)))
The feature was originally implemented for a voicemail feature. There would be a "voicemail" master user that would have permission to write new mails to users' "voicemail" mailbox, but nothing else.
You could have a similar "spam" master user that only has access to users' "Spam" mailbox (for training spam bayesian or whatever).
Anyway, did you try my suggestion on how to make it work the way you wanted? If it doesn't work yet, I can change the code to make it work:
You could try if having your userdb return master_user=%u field would make it work the way you want.
On Fri, 2010-04-16 at 16:57 +0400, Неворотин Вадим wrote:
I've add
$ENV{'MASTER_USER'} = $ENV{'USER'};
to my postlogin-imap script, and it looks like that all is working, thank you!!! I'll test it next week, but as I see ACL and base operations work, so I think that all other works too))
But what does it mean when I return in master_user field current user's name?)))
It means exactly what you do in your post-login script. It sets master_user to same as user.
But if I return in master_user not a current user name, but something else?))) What master_user field control?))) (Sorry, I can't find any information about this feature[?])
master_user is used for the ACL checks. Currently it doesn't do anything else. So if you set master_user to "foo", it uses foo's ACLs when determining access to mailboxes. There's nothing special about master users after login, they're just usernames as any other usernames are.
Thank you for your answer! I'll try to use it for my autoconfiguration script after weekends)) I use AD as userdb and passdb and have a group mailboxes, but main users for this mailboxes hasn't got any password. And I need automatically subscribe my users to new group maiboxes. So "full-access" masteruser is really good for me[?]
2010/4/16 Timo Sirainen tss@iki.fi
On Fri, 2010-04-16 at 16:57 +0400, Неворотин Вадим wrote:
I've add
$ENV{'MASTER_USER'} = $ENV{'USER'};
to my postlogin-imap script, and it looks like that all is working, thank you!!! I'll test it next week, but as I see ACL and base operations work, so I think that all other works too))
But what does it mean when I return in master_user field current user's name?)))
It means exactly what you do in your post-login script. It sets master_user to same as user.
But if I return in master_user not a current user name, but something else?))) What master_user field control?))) (Sorry, I can't find any information about this feature[?])
master_user is used for the ACL checks. Currently it doesn't do anything else. So if you set master_user to "foo", it uses foo's ACLs when determining access to mailboxes. There's nothing special about master users after login, they're just usernames as any other usernames are.
participants (3)
-
Eric Rostetter
-
Timo Sirainen
-
Неворотин Вадим