Mark Crispin wrote: > > On Fri, 28 Mar 2003, Carl Stehle wrote: > > 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? > > 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. > > > 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. > > 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.
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). > > > 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. > > 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.... ;-) 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
