dovecot - Mar 2009 - ACL changes not respected by already loged in clients

Hi *,

and yet another ACL problem.  ;-)

User A allows User B to access his mailbox foobar:

  * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
AUTH=PLAIN] Dovecot ready.
  l login userA secret
  l OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT
THREAD=REFERENCES MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS
LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN
CONTEXT=SEARCH ACL RIGHTS=texk ANNOTATEMORE] Logged in
  s setacl "INBOX/foobar" "B at example.com" eilprwtsd
  s OK Setacl complete.
  g getacl INBOX/foobar
  * ACL "INBOX/foobar" "B at example.com" eilprwtsd "A
at example.com" lrwstipekxacd

User B logs in to dovecot and sees the newly accessible mailbox:

  * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
AUTH=PLAIN] Dovecot ready.
  l login zwei 2
  l OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT
THREAD=REFERENCES MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS
LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN
CONTEXT=SEARCH ACL RIGHTS=texk ANNOTATEMORE] Logged in
  l list "" "*"
  * LIST (\Noselect \HasChildren) "/" "user"
  * LIST (\Noselect \HasChildren) "/" "user/A at
example.com"
  * LIST (\HasChildren) "/" "INBOX"
  * LIST (\HasNoChildren) "/" "INBOX/Gesendet"
  * LIST (\HasChildren) "/" "user/A at example.com/foobar"
  l OK List completed.
  se select  "user/A at example.com/foobar"
  * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
  * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags
permitted.
  * 1 EXISTS
  * 1 RECENT
  * OK [UIDVALIDITY 1236104897] UIDs valid
  * OK [UIDNEXT 2] Predicted next UID
  * OK [HIGHESTMODSEQ 1]

Now User A changes his mind:

  s setacl "INBOX/foobar" "B at example.com" ""
  s OK Setacl complete.
  g getacl INBOX/foobar
  * ACL "INBOX/foobar" "A at example.com" lrwstipekxacd
  g OK Getacl completed.

but as long as User B stays loged in, he is not affected, in fact he
still can read A's mails:

  se select  "user/A at example.com/foobar"
  * OK [CLOSED]
  * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
  * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags
permitted.
  * 1 EXISTS
  * 0 RECENT
  * OK [UIDVALIDITY 1236104897] UIDs valid
  * OK [UIDNEXT 2] Predicted next UID
  * OK [HIGHESTMODSEQ 1]
  se OK [READ-WRITE] Select completed.
  f101 fetch 1 FAST
  * 1 FETCH (FLAGS (\Seen) INTERNALDATE "04-Mar-2009 13:11:06 +0100"
RFC822.SIZE 3652)
  f101 OK Fetch completed.

I think ACL changes should take immediate effect, or at least should be
re-checked in reasonable intervals (which imo shouldn't exceed a few
seconds).

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer:   Frank Koormann,  Bernhard Reiter,  Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090305/3c7731ba/attachment-0002.bin>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 5 Mar 2009, Sascha Wilde wrote:
> I think ACL changes should take immediate effect, or at least should be
> re-checked in reasonable intervals (which imo shouldn't exceed a few
> seconds).
Although I see the problem in your scenario, it is rather uncommon to 
recalculate ACLs for already running processes, esp. not in intervals of 
seconds. Did you tried it in Windows or Unix?

Maybe, some "ACL push" plugin would help, that pushes ACL changes to 
processes that are logged in currently.

Bye,

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBSbDLwHWSIuGy1ktrAQJvLQgAi0YF5kgTOurFTEHja7Fma+GgENdpVhz3
KrXiPez4Y6ifa66/d9AuYV9pJLy3MpajvI3pFJyPiNbexfzimDc38pOD9Hebge8I
x15lpl6LRGIWSIUCHWMZXpylQUd6lRQG5UYDSYtemS64ebdPDJCzhPaHFCcbAjB9
Azy28E+Yar5LqeIh1hJajnB3ZKbhdevgc/6hZ7oM9KZXZkJnmQXyduhaXVYoQDf4
TPrNvK4c9FgehgPVQWiZKxQqSTlz/N5Oo5LOkCfeuhyGuqvObQMhmY6AVg6LhxSJ
e4n+adJtCu02+p6vJllWHlBBcypNmO4KJOxxbxwlcZuksBOBj/KI2w==YOhz
-----END PGP SIGNATURE-----

On Thu, 2009-03-05 at 18:18 +0100, Sascha Wilde wrote:
> I think ACL changes should take immediate effect, or at least should be
> re-checked in reasonable intervals (which imo shouldn't exceed a few
> seconds).
I think this should work:

acl = vfile:/etc/dovecot/acls:cache_secs=1

The default is 5 minutes. I suppose it could be lower. 30 seconds maybe?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090402/b94b5511/attachment-0002.bin>

On 4/2/2009 6:24 PM, Timo Sirainen wrote:
>> I think ACL changes should take immediate effect, or at least
>> should be re-checked in reasonable intervals (which imo shouldn't
>> exceed a few seconds).
> I think this should work:
> 
> acl = vfile:/etc/dovecot/acls:cache_secs=1
> 
> The default is 5 minutes. I suppose it could be lower. 30 seconds
> maybe?
I guess the answer to that depends on the extra load it puts on the
system... I'm guessing you were caching it for a reason?

-- 

Best regards,

Charles