On Mon, 31 Mar 2003, Carl Stehle wrote: > 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).
Right! In fact, that is completely *impractical* for the environment that imapd was designed for... ;-) > 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. Yup. > 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? 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 -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
