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. > 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.... ;-) -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
