Subject: ACL support in imapd

From: John Carver <[email-masked]>
Date: Tue, 11 Mar 2003 09:18:08 -0800 (PST)

Has ACL support (rfc2086) been added to imapd?  If not, are there any plans to do so?  I'm planning to evaluate Bynari's InsightConnector which uses this feature.

TIA - Dude

---------------------------------
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online

---

From: Mark Crispin <[email-masked]>
Date: Tue, 11 Mar 2003 15:56:18 -0800 (Pacific Standard Time)

On Tue, 11 Mar 2003, John Carver wrote:
> Has ACL support (rfc2086) been added to imapd?  If not, are there any
> plans to do so?  I'm planning to evaluate Bynari's InsightConnector
> which uses this feature.

At the present time, UW imapd does not have ACL support.  Unfortunately,
the design of RFC 2086 does not work well to represent UNIX filesystem
access controls.  There does not appear to be a way to implement RFC 2086
with UNIX filesystem access controls in a way that is (1) useful and (2)
compliant with RFC 2086.

These problems appear to be addressed in a new specification, called ACL2,
described in draft-ietf-imapext-acl-07.txt.  I plan to implement ACL2 in
UW imapd as soon as the dust settles on its specification.

I will be happy to discuss with Bynari about how to proceed, especially as
there is interest at UW about InsightConnector.  Ideally, InsightConnector
should work with any IMAP server, including ones which do not have ACL or
ACL2.

-- Mark --

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

---

From: Carl Stehle <[email-masked]>
Date: Fri, 28 Mar 2003 12:00:38 -0800

> should work with any IMAP server, including ones which do not have ACL or

Are the problems with implementing ACL support in UW imapd on UNIX
filesystems all related to UNIX filesystem permissions, or are there some
general issues with RFC 2086?

We are looking into adding ACL support using a simple 'advisory' database to
store the ACLs, and check against when executing imap commands. In this case,
there is no dependence on any underlying file system permission controls,
although an external database is required.

Also, do you have any recommendations as to where ACL support would best
be added? We are finding that mods to the imap command parser (imapd.c),
mailbox access routines (mail.c), and individual drivers are all needed.

-- 
Carl Stehle

---

From: Mark Crispin <[email-masked]>
Date: Fri, 28 Mar 2003 16:31:18 -0800 (Pacific Standard Time)

> general issues with RFC 2086?

For the most part, it's the former; or more specifically, the difficulty
in implementing filesystem permissions (such as on UNIX) in a useful way
in the RFC 2086 context.

> although an external database is required.

Actually, there is a dependency on the underlying filesystem; nothing in
an advisory ACL database can give you access if the underlying filesystem
permission controls prohibit it!

For the most part, you end up with just being able to do an additional,
IMAP-only (not enforced against non-IMAP) access control over and above
what the filesystem does.

> mailbox access routines (mail.c), and individual drivers are all needed.

This is correct: you need to implement the commands in imapd.c, the
general routines in mail.c, and then routines in individual drivers.  Note
the existing IMAP client routines for RFC 2086 style ACLs; they will give
you a general framework to follow.

For example, in mail.c you'll probably want a mail_setacl() with a
prototype of:

long mail_setacl (MAILSTREAM *stream,char *mailbox,char *id,char *rights);

to correspond with the existing imap_setacl().

This also leads you to mail.h additions and additions to the driver
dispatch table.

If you allow a null driver dispatch, you can simplify things by
implementing the local file ACL stuff once in the dummy driver, the way
that list and lsub are.  That way, you'll only have to do it once, and
just have null entries in the other driver dispatches.  That "dummy"
driver is no dummy; it's actually quite a smartie....  ;-)

-- Mark --

---

From: Carl Stehle <[email-masked]>
Date: Mon, 31 Mar 2003 19:17:11 -0800

> what the filesystem does.

Or, if the file system permissions are set consistent with 'maximal' ACL
rights, then there are no file system restrictions and all enforcement is
performed using the advisory database. Admittedly, this is not practical
in all environments, but it is in some (particularly, 'personal' systems).

> driver is no dummy; it's actually quite a smartie....  ;-)

Interesting. So, by layering this way it does not matter how generic or
environment-specific the ACL support turns out to be. Nor does the method
for managing ACLs matter, as that is localized in the 'dummy' driver,
and in any environment-dependent code.

One other area that concerns us is modifying the behaviour of the 
existing imap commands to comply with ACL rights. So far we have found
about half a dozen driver-specific places to change (in mbx and unix drivers)
for checking flags that can not be handled by imapd.c; imapd.c (or new 
routines in mail.c) can check the rights needed for command execution,
but not the imap command 'side-effects' which affect flags. Are there
any hooks where flag-dependent command behaviour can be controlled (e.g.
allowing a 'COPY' without setting certain flags in the 'to' mailbox)
or does this need to be done specifically within each driver's affected
routines?

We appreciate all of your comments; making mods to an existing architecture
in the dark has often proven to be a recipe for disaster, for us, at least!

-- 
Carl Stehle

---

From: Mark Crispin <[email-masked]>
Date: Mon, 31 Mar 2003 19:45:33 -0800 (Pacific Standard Time)

> in all environments, but it is in some (particularly, 'personal' systems).

Right!  In fact, that is completely *impractical* for the environment that
imapd was designed for...  ;-)

> and in any environment-dependent code.

Yup.

> or does this need to be done specifically within each driver's affected

I suggest that there *not* be any changes made in imapd.c other than what
is necessary to add support for the various RFC 2086 commands.  Nor should
there be any changes in mail.c other than what is necessary to add the
dispatch calls to the drivers.

So, everything is done in the drivers.  You may want to remove drivers
that you don't want to support rather than implementing ACL in them.  The
list stuff is mostly handled by the dummy driver, and the rest is handled
by the individual format driver (unix, mbx, etc.).

-- Mark --