Subject: Re: another question about ACL -08
From: Mark Crispin <[email-masked]>
To: Michael Fair <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Mon, 7 Jul 2003 05:26:49 -0700 (PDT)
List-Id: <ietf-imapext.imc.org>

On Mon, 7 Jul 2003, Michael Fair wrote:
> Won't this make writing generic IMAPv4 management clients
> that manipulate ACLs difficult because it has to figure
> out what semantics it has...

I agree that there should be some means for the client to learn the
semantics in advance.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: "Michael Fair" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: "Alexey Melnikov" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Subject: Re: another question about ACL -08
Date: Mon, 7 Jul 2003 01:38:00 -0700
Organization: DaClubhouse
Sender: [email-masked]

> On Sun, 6 Jul 2003, Michael Fair wrote:
> > Does this mean that only one group will be allowed to have an
> > entry in the ACL?  Or that an individual server might opt to use those
> > semantics and so ACL semantics will vary from one server to the next?
>
> The latter
>
> > If there can be more than one group or user associated in the ACL
> > how do you delete/change just one of them without having to fetch the
whole
> > list and restore it without the intended target?
>
> ACL STORE and ACL DELETE act on a single identifier/rights pair.
>
> In a server that only allows one group, ACL STORE with a different
> group identifer will replace the existing group identifer.  In one which
> has multiple groups, it will add a new identifier/rights pair.

Thanks for the explanation.

> This overloading of functionality concerns me, but apparently the
> alternative is not acceptable.

Won't this make writing generic IMAPv4 management clients
that manipulate ACLs difficult because it has to figure
out what semantics it has... Or is it just the case that
any client wanting to be portable always does a DELETE then
STORE regardless of server (or the most savvy clients actually
trying to determine behavior based on server).

-- Michael --

Date: Sun, 6 Jul 2003 23:54:24 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Michael Fair <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

On Sun, 6 Jul 2003, Michael Fair wrote:
> Does this mean that only one group will be allowed to have an
> entry in the ACL?  Or that an individual server might opt to use those
> semantics and so ACL semantics will vary from one server to the next?

The latter

> If there can be more than one group or user associated in the ACL
> how do you delete/change just one of them without having to fetch the whole
> list and restore it without the intended target?

ACL STORE and ACL DELETE act on a single identifier/rights pair.

In a server that only allows one group, ACL STORE with a different
group identifer will replace the existing group identifer.  In one which
has multiple groups, it will add a new identifier/rights pair.

This overloading of functionality concerns me, but apparently the
alternative is not acceptable.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: "Michael Fair" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>, "Mark Crispin" <[email-masked]>
Cc: "IMAP Extensions WG" <[email-masked]>
Subject: Re: another question about ACL -08
Date: Sun, 6 Jul 2003 22:50:22 -0700
Organization: DaClubhouse
Sender: [email-masked]

> Mark Crispin wrote:
>
> > On Wed, 2 Jul 2003, Alexey Melnikov wrote:
> > > > I don't see this as a significant benefit for clients (I doubt I'd
ever
> > > > want to 'rename' an ACL identifier) and only increases
implementation
> > > > complexity for ACL systems that don't use 'chgrp' or 'chown'.
> > > I tend to agree. This is one of "nice to have" features and I have a
list of 4-5
> > > other commands I've refused to put into the document.
> >
> > You still need to say explicitly that ACL STORE can do an implicit ACL
> > DELETE of some other identifer/rights pair;
>
> I've added the text you proposed. Also the following example:
>
>    C: B001 LIST (ACL) "" INBOX
>    S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") (
>        "group=Devel" "rwipslt"))))
>    S: B001 OK List with acl info completed
>    C: B002 ACL STORE Inbox group=PSO rwipslte
>    S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") (
>        "group=PSO" "rwipslte"))))
>    S: B002 OK Setacl complete
>
> > and there ought to be a way
> > for the client to know that such a thing would happen in advance.
>
> Suggestions are welcome.
>
> I was thinking that this should be part of ACL model description.

Does this mean that only one group will be allowed to have an
entry in the ACL?  Or that an individual server might opt to use those
semantics and so ACL semantics will vary from one server to the next?

If there can be more than one group or user associated in the ACL
how do you delete/change just one of them without having to fetch the whole
list and restore it without the intended target?

-- Michael --

Date: Sat, 05 Jul 2003 14:50:22 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

Mark Crispin wrote:

> On Wed, 2 Jul 2003, Alexey Melnikov wrote:
> > > I don't see this as a significant benefit for clients (I doubt I'd ever
> > > want to 'rename' an ACL identifier) and only increases implementation
> > > complexity for ACL systems that don't use 'chgrp' or 'chown'.
> > I tend to agree. This is one of "nice to have" features and I have a list of 4-5
> > other commands I've refused to put into the document.
>
> You still need to say explicitly that ACL STORE can do an implicit ACL
> DELETE of some other identifer/rights pair;

I've added the text you proposed. Also the following example:

   C: B001 LIST (ACL) "" INBOX
   S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") (
       "group=Devel" "rwipslt"))))
   S: B001 OK List with acl info completed
   C: B002 ACL STORE Inbox group=PSO rwipslte
   S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") (
       "group=PSO" "rwipslte"))))
   S: B002 OK Setacl complete

> and there ought to be a way
> for the client to know that such a thing would happen in advance.

Suggestions are welcome.

I was thinking that this should be part of ACL model description.

Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

Date: Wed, 2 Jul 2003 10:50:18 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Rob Siemborski <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

On Wed, 2 Jul 2003, Alexey Melnikov wrote:
> > I don't see this as a significant benefit for clients (I doubt I'd ever
> > want to 'rename' an ACL identifier) and only increases implementation
> > complexity for ACL systems that don't use 'chgrp' or 'chown'.
> I tend to agree. This is one of "nice to have" features and I have a list of 4-5
> other commands I've refused to put into the document.

You still need to say explicitly that ACL STORE can do an implicit ACL
DELETE of some other identifer/rights pair; and there ought to be a way
for the client to know that such a thing would happen in advance.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 02 Jul 2003 09:07:04 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Rob Siemborski <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

Rob Siemborski wrote:

> On Tue, 1 Jul 2003, Mark Crispin wrote:
>
> > There should be an ACL RENAME command which will change the identifier of
> > a particular identifier,rights pair while preserving the rest of the ACL.
> >
> > E.g., given an mailbox foo with an ACL of
> >       owner lrswipxtea group=devel lrs anyone ""
> > the command
> >       ACL RENAME foo group=devel group=test
> > should result in an ACL of
> >       owner lrswipxtea group=test lrs anyone ""
> >
> > This translates into a chown or chgrp in UNIX, and on other systems is a
> > a simple alternative form of ACL SET.
> >
> > Otherwise, the "chgrp" type operation would require an ACL SET echoing
> > what is already there.
>
> Is there a serious functionality gain here?
>
> I don't see this as a significant benefit for clients (I doubt I'd ever
> want to 'rename' an ACL identifier) and only increases implementation
> complexity for ACL systems that don't use 'chgrp' or 'chown'.

I tend to agree. This is one of "nice to have" features and I have a list of 4-5
other commands I've refused to put into the document.

Alexey

Date: Wed, 02 Jul 2003 08:26:47 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

Mark Crispin wrote:

> On Fri, 20 Jun 2003, Lawrence Greenfield wrote:
> > . Why is there no 'anonymous' identifier in addition to 'anyone' and
> > 'authuser'?
>
> Is there a reason that we would want anonymous to have rights different
> from anyone, given that authuser now exists?

No. But I think Larry suggests to add 'anonymous' as a synonym for 'anyone'.
Personally, I don't care either way. 'anonymous' is an implementation specific
thing for Cyrus-based servers.

> The only use would be to grant anonymous rights that some authorized users
> don't have.  Seems silly to me.
>
> I also noted this text:
>
>    [...]   For example,
>    in an implementation that uses unix mode bits, the rights "wisd" are
>    tied, the "a" right is always granted to the owner of a mailbox and
>    is never granted to another user.
>
> "wisd" should be replaced with "swite".

Fixed. Thanks.

Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

Subject: Re: ACL2 rule identifiers
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked]
Date: 02 Jul 2003 06:15:47 +0300
Sender: [email-masked]

On Wed, 2003-07-02 at 05:23, Mark Crispin wrote:
> On Tue, 2 Jul 2003, Timo Sirainen wrote:
> > Preferrably there shouldn't need to be multiple rules. Make one that
> > works with all cases.
> 
> That would be desirable, but I don't think that it is possible.  If one is
> implementing IMAP on a pre-existing mail store, the mail store's existing
> means of access control constrains what can be done in IMAP.

I think it would be possible with enough thinking. You only have to be
able to describe the existing limited ACLs with the new flexible one,
not the other way around. Changing the ACLs would of course need some
rules what to do if underlying store has more limited ACL support.

BTW. Has anyone checked how Posix filesystem ACLs work? How well would
it work with current rules?

> So I think that hopes for a server implementing multiple rules with
> clients being able to pick and choose is a pipe-dream.  More likely, the
> server will dictate and the client must comply.

Clients can make it easier to use different rules, but users will still
need to learn how to use them. I can easily imagine all the cries when
the new IMAP server works differently than old one..

Date: Tue, 1 Jul 2003 19:41:54 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Organization: Networks & Distributed Computing
Sender: [email-masked]

If that is what it is intended, it should be explicitly stated in the
specification.

Effectively deleting an existing ACL as a side effect of storing an ACL
seems to me to be stretching the definition of "modification", and unless
it is explicitly stated that this is expected and acceptable behavior
there are bound to be flames if a server does that.

I'll drop my request for ACL RENAME if this explicit statement is added,
perhaps with an example, e.g. "in some mail stores, a mailbox can be a
member of only one group.  Thus, doing an ACL STORE that sets a different
group from what is already in the ACL may have the effect of doing an
implicit ACL DELETE of the existing group's identifier/rights pair."

On Tue, 1 Jul 2003, Rob Siemborski wrote:
> > Either that, or allow ACL STORE with a new identifier to arbitrarily do an
> > implicit ACL DELETE of some other identifier, and *document* it in the
> > specification that a server may do this.
> This is significantly more palatable to me, especially given this text in
> the ACL STORE definition:
>       An ACL2 server MAY modify one or more ACL for one or more identifier
>       as a side effect of modifying the ACL specified in ACL STORE. If the
>       server does that it MUST send untagged LIST response with ACL information
>       (see section 5.1) to notify the client about the changes made.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 1 Jul 2003 22:35:16 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

On Tue, 1 Jul 2003, Mark Crispin wrote:

> Adding ACL RENAME makes this quite a bit easier.

But it seems to be functionality that already exists (see below).

> Either that, or allow ACL STORE with a new identifier to arbitrarily do an
> implicit ACL DELETE of some other identifier, and *document* it in the
> specification that a server may do this.

This is significantly more palatable to me, especially given this text in
the ACL STORE definition:

      An ACL2 server MAY modify one or more ACL for one or more identifier
      as a side effect of modifying the ACL specified in ACL STORE. If the
      server does that it MUST send untagged LIST response with ACL information
      (see section 5.1) to notify the client about the changes made.

Which seems to do exactly what you want here.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 1 Jul 2003 19:23:44 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: [email-masked]
Subject: Re: ACL2 rule identifiers
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 2 Jul 2003, Timo Sirainen wrote:
> Preferrably there shouldn't need to be multiple rules. Make one that
> works with all cases.

That would be desirable, but I don't think that it is possible.  If one is
implementing IMAP on a pre-existing mail store, the mail store's existing
means of access control constrains what can be done in IMAP.

The whole reason we got into this mess was that RFC 2086 turned out to be
unimplementable in any reasonable way with one rather important form of
pre-existing mail store.

"First rule wins" with no inheritance would be fine for me (and would
allow the deletion of negative rights), but I don't know if it would be
suitable for people from other environments (e.g. Cyrus).

So I think that hopes for a server implementing multiple rules with
clients being able to pick and choose is a pipe-dream.  More likely, the
server will dictate and the client must comply.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Subject: ACL2 rule identifiers
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Date: 02 Jul 2003 04:52:54 +0300
Sender: [email-masked]

I think multiple rule identifiers are a very bad idea. Clients will most
likely get some of the details wrong in rules they haven't been tested
against. Servers will probably have to implement multiple rules so admin
can choose his preferred one. Worst of all, they confuse users.

Suppose a user has gone through all the trouble to figure out how one
rule works. Then he switches to another IMAP server (another ISP) that
uses different rule. He might not realize that the rule changed. He
might not even know that different rules exist. So he happily uses the
old way to do things, and ends up sharing mailboxes to wrong people.

At the very least server should be able to advertise multiple rules and
client should be able to choose which one it wants to use.

Preferrably there shouldn't need to be multiple rules. Make one that
works with all cases. Maybe just add ordering into the rules with first
matching rule wins logic, just like firewall rules usually have.

Date: Tue, 1 Jul 2003 17:30:26 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 1 Jul 2003, Rob Siemborski wrote:
> > There should be an ACL RENAME command
> Is there a serious functionality gain here?

Yes.  chgrp is a fairly important part of the UNIX filesystem access
control model, and without a way to represent it (even with ACL SET) a
server using the filesystem access control model is crippled.

> I don't see this as a significant benefit for clients (I doubt I'd ever
> want to 'rename' an ACL identifier) and only increases implementation
> complexity for ACL systems that don't use 'chgrp' or 'chown'.

A mailbox has an ACL for group=sys.  You want it to have group=devel
isntead.

One obvious means of implementation (ACL DELETE + ACL STORE) won't work,
since you can't ACL STORE a new identifier or ACL DELETE an existing
identifier.  The only way is by ACL SET, which does quite a bit more than
just the chgrp (even if it's a big no-op).

How is the client supposed to know this?

> > How is ACL DELETE implemented if it is not actually possible to delete an
> > identifier?
> In the MOST-SPECIFIC case I'd expect this to set the rights to
> those of anyone.
> In the UNION case I'd expect this to set the rights to"".
> But I'd probably expect the server to say NO if it couldn't actually
> delete the identifier.

Well, I agree about saying NO to ACL DELETE and to ACL STORE that tries to
add an identifier.  But I don't see how the client is supposed to know how
to do this.

Adding ACL RENAME makes this quite a bit easier.

Either that, or allow ACL STORE with a new identifier to arbitrarily do an
implicit ACL DELETE of some other identifier, and *document* it in the
specification that a server may do this.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 1 Jul 2003 20:09:06 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

On Tue, 1 Jul 2003, Mark Crispin wrote:

> There should be an ACL RENAME command which will change the identifier of
> a particular identifier,rights pair while preserving the rest of the ACL.
>
> E.g., given an mailbox foo with an ACL of
> 	owner lrswipxtea group=devel lrs anyone ""
> the command
> 	ACL RENAME foo group=devel group=test
> should result in an ACL of
> 	owner lrswipxtea group=test lrs anyone ""
>
> This translates into a chown or chgrp in UNIX, and on other systems is a
> a simple alternative form of ACL SET.
>
> Otherwise, the "chgrp" type operation would require an ACL SET echoing
> what is already there.

Is there a serious functionality gain here?

I don't see this as a significant benefit for clients (I doubt I'd ever
want to 'rename' an ACL identifier) and only increases implementation
complexity for ACL systems that don't use 'chgrp' or 'chown'.

> How is ACL DELETE implemented if it is not actually possible to delete an
> identifier?  I'm not sure if it should set the rights to "" or to those of
> anyone.

In the MOST-SPECIFIC case I'd expect this to set the rights to
those of anyone.

In the UNION case I'd expect this to set the rights to"".

But I'd probably expect the server to say NO if it couldn't actually
delete the identifier.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 1 Jul 2003 16:34:03 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: another question about ACL -08
Organization: Networks & Distributed Computing
Sender: [email-masked]

There should be an ACL RENAME command which will change the identifier of
a particular identifier,rights pair while preserving the rest of the ACL.

E.g., given an mailbox foo with an ACL of
	owner lrswipxtea group=devel lrs anyone ""
the command
	ACL RENAME foo group=devel group=test
should result in an ACL of
	owner lrswipxtea group=test lrs anyone ""

This translates into a chown or chgrp in UNIX, and on other systems is a
a simple alternative form of ACL SET.

Otherwise, the "chgrp" type operation would require an ACL SET echoing
what is already there.

How is ACL DELETE implemented if it is not actually possible to delete an
identifier?  I'm not sure if it should set the rights to "" or to those of
anyone.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 1 Jul 2003 16:16:57 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Fri, 20 Jun 2003, Lawrence Greenfield wrote:
> . Why is there no 'anonymous' identifier in addition to 'anyone' and
> 'authuser'?

Is there a reason that we would want anonymous to have rights different
from anyone, given that authuser now exists?

The only use would be to grant anonymous rights that some authorized users
don't have.  Seems silly to me.

I also noted this text:

   [...]   For example,
   in an implementation that uses unix mode bits, the rights "wisd" are
   tied, the "a" right is always granted to the owner of a mailbox and
   is never granted to another user.

"wisd" should be replaced with "swite".

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 7 Jul 2003 05:26:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Michael Fair <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

On Mon, 7 Jul 2003, Michael Fair wrote:
> Won't this make writing generic IMAPv4 management clients
> that manipulate ACLs difficult because it has to figure
> out what semantics it has...

I agree that there should be some means for the client to learn the
semantics in advance.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: "Michael Fair" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: "Alexey Melnikov" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Subject: Re: another question about ACL -08
Date: Mon, 7 Jul 2003 01:38:00 -0700
Organization: DaClubhouse
Sender: [email-masked]

> On Sun, 6 Jul 2003, Michael Fair wrote:
> > Does this mean that only one group will be allowed to have an
> > entry in the ACL?  Or that an individual server might opt to use those
> > semantics and so ACL semantics will vary from one server to the next?
>
> The latter
>
> > If there can be more than one group or user associated in the ACL
> > how do you delete/change just one of them without having to fetch the
whole
> > list and restore it without the intended target?
>
> ACL STORE and ACL DELETE act on a single identifier/rights pair.
>
> In a server that only allows one group, ACL STORE with a different
> group identifer will replace the existing group identifer.  In one which
> has multiple groups, it will add a new identifier/rights pair.

Thanks for the explanation.

> This overloading of functionality concerns me, but apparently the
> alternative is not acceptable.

Won't this make writing generic IMAPv4 management clients
that manipulate ACLs difficult because it has to figure
out what semantics it has... Or is it just the case that
any client wanting to be portable always does a DELETE then
STORE regardless of server (or the most savvy clients actually
trying to determine behavior based on server).

-- Michael --

Date: Sun, 6 Jul 2003 23:54:24 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Michael Fair <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

On Sun, 6 Jul 2003, Michael Fair wrote:
> Does this mean that only one group will be allowed to have an
> entry in the ACL?  Or that an individual server might opt to use those
> semantics and so ACL semantics will vary from one server to the next?

The latter

> If there can be more than one group or user associated in the ACL
> how do you delete/change just one of them without having to fetch the whole
> list and restore it without the intended target?

ACL STORE and ACL DELETE act on a single identifier/rights pair.

In a server that only allows one group, ACL STORE with a different
group identifer will replace the existing group identifer.  In one which
has multiple groups, it will add a new identifier/rights pair.

This overloading of functionality concerns me, but apparently the
alternative is not acceptable.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: "Michael Fair" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>, "Mark Crispin" <[email-masked]>
Cc: "IMAP Extensions WG" <[email-masked]>
Subject: Re: another question about ACL -08
Date: Sun, 6 Jul 2003 22:50:22 -0700
Organization: DaClubhouse
Sender: [email-masked]

> Mark Crispin wrote:
>
> > On Wed, 2 Jul 2003, Alexey Melnikov wrote:
> > > > I don't see this as a significant benefit for clients (I doubt I'd
ever
> > > > want to 'rename' an ACL identifier) and only increases
implementation
> > > > complexity for ACL systems that don't use 'chgrp' or 'chown'.
> > > I tend to agree. This is one of "nice to have" features and I have a
list of 4-5
> > > other commands I've refused to put into the document.
> >
> > You still need to say explicitly that ACL STORE can do an implicit ACL
> > DELETE of some other identifer/rights pair;
>
> I've added the text you proposed. Also the following example:
>
>    C: B001 LIST (ACL) "" INBOX
>    S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") (
>        "group=Devel" "rwipslt"))))
>    S: B001 OK List with acl info completed
>    C: B002 ACL STORE Inbox group=PSO rwipslte
>    S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") (
>        "group=PSO" "rwipslte"))))
>    S: B002 OK Setacl complete
>
> > and there ought to be a way
> > for the client to know that such a thing would happen in advance.
>
> Suggestions are welcome.
>
> I was thinking that this should be part of ACL model description.

Does this mean that only one group will be allowed to have an
entry in the ACL?  Or that an individual server might opt to use those
semantics and so ACL semantics will vary from one server to the next?

If there can be more than one group or user associated in the ACL
how do you delete/change just one of them without having to fetch the whole
list and restore it without the intended target?

-- Michael --

Date: Sat, 05 Jul 2003 14:50:22 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

Mark Crispin wrote:

> On Wed, 2 Jul 2003, Alexey Melnikov wrote:
> > > I don't see this as a significant benefit for clients (I doubt I'd ever
> > > want to 'rename' an ACL identifier) and only increases implementation
> > > complexity for ACL systems that don't use 'chgrp' or 'chown'.
> > I tend to agree. This is one of "nice to have" features and I have a list of 4-5
> > other commands I've refused to put into the document.
>
> You still need to say explicitly that ACL STORE can do an implicit ACL
> DELETE of some other identifer/rights pair;

I've added the text you proposed. Also the following example:

   C: B001 LIST (ACL) "" INBOX
   S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") (
       "group=Devel" "rwipslt"))))
   S: B001 OK List with acl info completed
   C: B002 ACL STORE Inbox group=PSO rwipslte
   S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") (
       "group=PSO" "rwipslte"))))
   S: B002 OK Setacl complete

> and there ought to be a way
> for the client to know that such a thing would happen in advance.

Suggestions are welcome.

I was thinking that this should be part of ACL model description.

Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

Date: Wed, 2 Jul 2003 10:50:18 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Rob Siemborski <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

On Wed, 2 Jul 2003, Alexey Melnikov wrote:
> > I don't see this as a significant benefit for clients (I doubt I'd ever
> > want to 'rename' an ACL identifier) and only increases implementation
> > complexity for ACL systems that don't use 'chgrp' or 'chown'.
> I tend to agree. This is one of "nice to have" features and I have a list of 4-5
> other commands I've refused to put into the document.

You still need to say explicitly that ACL STORE can do an implicit ACL
DELETE of some other identifer/rights pair; and there ought to be a way
for the client to know that such a thing would happen in advance.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 02 Jul 2003 09:07:04 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Rob Siemborski <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

Rob Siemborski wrote:

> On Tue, 1 Jul 2003, Mark Crispin wrote:
>
> > There should be an ACL RENAME command which will change the identifier of
> > a particular identifier,rights pair while preserving the rest of the ACL.
> >
> > E.g., given an mailbox foo with an ACL of
> >       owner lrswipxtea group=devel lrs anyone ""
> > the command
> >       ACL RENAME foo group=devel group=test
> > should result in an ACL of
> >       owner lrswipxtea group=test lrs anyone ""
> >
> > This translates into a chown or chgrp in UNIX, and on other systems is a
> > a simple alternative form of ACL SET.
> >
> > Otherwise, the "chgrp" type operation would require an ACL SET echoing
> > what is already there.
>
> Is there a serious functionality gain here?
>
> I don't see this as a significant benefit for clients (I doubt I'd ever
> want to 'rename' an ACL identifier) and only increases implementation
> complexity for ACL systems that don't use 'chgrp' or 'chown'.

I tend to agree. This is one of "nice to have" features and I have a list of 4-5
other commands I've refused to put into the document.

Alexey

Date: Wed, 02 Jul 2003 08:26:47 -0600
From: Alexey Melnikov <[email-masked]>
Organization: Isode Limited
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: acl-08: questions
Sender: [email-masked]

Mark Crispin wrote:

> On Fri, 20 Jun 2003, Lawrence Greenfield wrote:
> > . Why is there no 'anonymous' identifier in addition to 'anyone' and
> > 'authuser'?
>
> Is there a reason that we would want anonymous to have rights different
> from anyone, given that authuser now exists?

No. But I think Larry suggests to add 'anonymous' as a synonym for 'anyone'.
Personally, I don't care either way. 'anonymous' is an implementation specific
thing for Cyrus-based servers.

> The only use would be to grant anonymous rights that some authorized users
> don't have.  Seems silly to me.
>
> I also noted this text:
>
>    [...]   For example,
>    in an implementation that uses unix mode bits, the rights "wisd" are
>    tied, the "a" right is always granted to the owner of a mailbox and
>    is never granted to another user.
>
> "wisd" should be replaced with "swite".

Fixed. Thanks.

Alexey
__________________________________________
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

Subject: Re: ACL2 rule identifiers
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked]
Date: 02 Jul 2003 06:15:47 +0300
Sender: [email-masked]

On Wed, 2003-07-02 at 05:23, Mark Crispin wrote:
> On Tue, 2 Jul 2003, Timo Sirainen wrote:
> > Preferrably there shouldn't need to be multiple rules. Make one that
> > works with all cases.
> 
> That would be desirable, but I don't think that it is possible.  If one is
> implementing IMAP on a pre-existing mail store, the mail store's existing
> means of access control constrains what can be done in IMAP.

I think it would be possible with enough thinking. You only have to be
able to describe the existing limited ACLs with the new flexible one,
not the other way around. Changing the ACLs would of course need some
rules what to do if underlying store has more limited ACL support.

BTW. Has anyone checked how Posix filesystem ACLs work? How well would
it work with current rules?

> So I think that hopes for a server implementing multiple rules with
> clients being able to pick and choose is a pipe-dream.  More likely, the
> server will dictate and the client must comply.

Clients can make it easier to use different rules, but users will still
need to learn how to use them. I can easily imagine all the cries when
the new IMAP server works differently than old one..

Date: Tue, 1 Jul 2003 19:41:54 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Organization: Networks & Distributed Computing
Sender: [email-masked]

If that is what it is intended, it should be explicitly stated in the
specification.

Effectively deleting an existing ACL as a side effect of storing an ACL
seems to me to be stretching the definition of "modification", and unless
it is explicitly stated that this is expected and acceptable behavior
there are bound to be flames if a server does that.

I'll drop my request for ACL RENAME if this explicit statement is added,
perhaps with an example, e.g. "in some mail stores, a mailbox can be a
member of only one group.  Thus, doing an ACL STORE that sets a different
group from what is already in the ACL may have the effect of doing an
implicit ACL DELETE of the existing group's identifier/rights pair."

On Tue, 1 Jul 2003, Rob Siemborski wrote:
> > Either that, or allow ACL STORE with a new identifier to arbitrarily do an
> > implicit ACL DELETE of some other identifier, and *document* it in the
> > specification that a server may do this.
> This is significantly more palatable to me, especially given this text in
> the ACL STORE definition:
>       An ACL2 server MAY modify one or more ACL for one or more identifier
>       as a side effect of modifying the ACL specified in ACL STORE. If the
>       server does that it MUST send untagged LIST response with ACL information
>       (see section 5.1) to notify the client about the changes made.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 1 Jul 2003 22:35:16 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

On Tue, 1 Jul 2003, Mark Crispin wrote:

> Adding ACL RENAME makes this quite a bit easier.

But it seems to be functionality that already exists (see below).

> Either that, or allow ACL STORE with a new identifier to arbitrarily do an
> implicit ACL DELETE of some other identifier, and *document* it in the
> specification that a server may do this.

This is significantly more palatable to me, especially given this text in
the ACL STORE definition:

      An ACL2 server MAY modify one or more ACL for one or more identifier
      as a side effect of modifying the ACL specified in ACL STORE. If the
      server does that it MUST send untagged LIST response with ACL information
      (see section 5.1) to notify the client about the changes made.

Which seems to do exactly what you want here.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 1 Jul 2003 19:23:44 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: [email-masked]
Subject: Re: ACL2 rule identifiers
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 2 Jul 2003, Timo Sirainen wrote:
> Preferrably there shouldn't need to be multiple rules. Make one that
> works with all cases.

That would be desirable, but I don't think that it is possible.  If one is
implementing IMAP on a pre-existing mail store, the mail store's existing
means of access control constrains what can be done in IMAP.

The whole reason we got into this mess was that RFC 2086 turned out to be
unimplementable in any reasonable way with one rather important form of
pre-existing mail store.

"First rule wins" with no inheritance would be fine for me (and would
allow the deletion of negative rights), but I don't know if it would be
suitable for people from other environments (e.g. Cyrus).

So I think that hopes for a server implementing multiple rules with
clients being able to pick and choose is a pipe-dream.  More likely, the
server will dictate and the client must comply.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Subject: ACL2 rule identifiers
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Date: 02 Jul 2003 04:52:54 +0300
Sender: [email-masked]

I think multiple rule identifiers are a very bad idea. Clients will most
likely get some of the details wrong in rules they haven't been tested
against. Servers will probably have to implement multiple rules so admin
can choose his preferred one. Worst of all, they confuse users.

Suppose a user has gone through all the trouble to figure out how one
rule works. Then he switches to another IMAP server (another ISP) that
uses different rule. He might not realize that the rule changed. He
might not even know that different rules exist. So he happily uses the
old way to do things, and ends up sharing mailboxes to wrong people.

At the very least server should be able to advertise multiple rules and
client should be able to choose which one it wants to use.

Preferrably there shouldn't need to be multiple rules. Make one that
works with all cases. Maybe just add ordering into the rules with first
matching rule wins logic, just like firewall rules usually have.

Date: Tue, 1 Jul 2003 17:30:26 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Rob Siemborski <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 1 Jul 2003, Rob Siemborski wrote:
> > There should be an ACL RENAME command
> Is there a serious functionality gain here?

Yes.  chgrp is a fairly important part of the UNIX filesystem access
control model, and without a way to represent it (even with ACL SET) a
server using the filesystem access control model is crippled.

> I don't see this as a significant benefit for clients (I doubt I'd ever
> want to 'rename' an ACL identifier) and only increases implementation
> complexity for ACL systems that don't use 'chgrp' or 'chown'.

A mailbox has an ACL for group=sys.  You want it to have group=devel
isntead.

One obvious means of implementation (ACL DELETE + ACL STORE) won't work,
since you can't ACL STORE a new identifier or ACL DELETE an existing
identifier.  The only way is by ACL SET, which does quite a bit more than
just the chgrp (even if it's a big no-op).

How is the client supposed to know this?

> > How is ACL DELETE implemented if it is not actually possible to delete an
> > identifier?
> In the MOST-SPECIFIC case I'd expect this to set the rights to
> those of anyone.
> In the UNION case I'd expect this to set the rights to"".
> But I'd probably expect the server to say NO if it couldn't actually
> delete the identifier.

Well, I agree about saying NO to ACL DELETE and to ACL STORE that tries to
add an identifier.  But I don't see how the client is supposed to know how
to do this.

Adding ACL RENAME makes this quite a bit easier.

Either that, or allow ACL STORE with a new identifier to arbitrarily do an
implicit ACL DELETE of some other identifier, and *document* it in the
specification that a server may do this.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 1 Jul 2003 20:09:06 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: another question about ACL -08
Sender: [email-masked]

On Tue, 1 Jul 2003, Mark Crispin wrote:

> There should be an ACL RENAME command which will change the identifier of
> a particular identifier,rights pair while preserving the rest of the ACL.
>
> E.g., given an mailbox foo with an ACL of
> 	owner lrswipxtea group=devel lrs anyone ""
> the command
> 	ACL RENAME foo group=devel group=test
> should result in an ACL of
> 	owner lrswipxtea group=test lrs anyone ""
>
> This translates into a chown or chgrp in UNIX, and on other systems is a
> a simple alternative form of ACL SET.
>
> Otherwise, the "chgrp" type operation would require an ACL SET echoing
> what is already there.

Is there a serious functionality gain here?

I don't see this as a significant benefit for clients (I doubt I'd ever
want to 'rename' an ACL identifier) and only increases implementation
complexity for ACL systems that don't use 'chgrp' or 'chown'.

> How is ACL DELETE implemented if it is not actually possible to delete an
> identifier?  I'm not sure if it should set the rights to "" or to those of
> anyone.

In the MOST-SPECIFIC case I'd expect this to set the rights to
those of anyone.

In the UNION case I'd expect this to set the rights to"".

But I'd probably expect the server to say NO if it couldn't actually
delete the identifier.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 1 Jul 2003 16:34:03 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: another question about ACL -08
Organization: Networks & Distributed Computing
Sender: [email-masked]

There should be an ACL RENAME command which will change the identifier of
a particular identifier,rights pair while preserving the rest of the ACL.

E.g., given an mailbox foo with an ACL of
	owner lrswipxtea group=devel lrs anyone ""
the command
	ACL RENAME foo group=devel group=test
should result in an ACL of
	owner lrswipxtea group=test lrs anyone ""

This translates into a chown or chgrp in UNIX, and on other systems is a
a simple alternative form of ACL SET.

Otherwise, the "chgrp" type operation would require an ACL SET echoing
what is already there.

How is ACL DELETE implemented if it is not actually possible to delete an
identifier?  I'm not sure if it should set the rights to "" or to those of
anyone.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 1 Jul 2003 16:16:57 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: acl-08: questions
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Fri, 20 Jun 2003, Lawrence Greenfield wrote:
> . Why is there no 'anonymous' identifier in addition to 'anyone' and
> 'authuser'?

Is there a reason that we would want anonymous to have rights different
from anyone, given that authuser now exists?

The only use would be to grant anonymous rights that some authorized users
don't have.  Seems silly to me.

I also noted this text:

   [...]   For example,
   in an implementation that uses unix mode bits, the rights "wisd" are
   tied, the "a" right is always granted to the owner of a mailbox and
   is never granted to another user.

"wisd" should be replaced with "swite".

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.