On Mon, 10 Mar 2003, Dale Woolridge wrote: > On 10-Mar-2003 13:37 Charlie Brady wrote: > | > | > > 1. Don't restrict the chroot() to a Maildir only. > | > > 2. Recommend use of a non-top-level Maildir scheme so that chroot() > | > > can avoid top-level. For example, recommend using ~/mail/Maildir > | > > as the inbox & chroot ~/mail instead of ~/mail/Maildir. Some > | > > systems may wish to chroot ~/Maildir though. > | > | "chroot" itself becomes problematic if you wish to have shared folders. > > Definitely. How is bincimap supporting shared folders right now?
As far as I can tell, only implicitly if permissions and path access permit shared access. There's no namespace support, so what doesn't exist within the user's personal folder heirarchy isn't accessible. > I think the chroot() benefit only exists in limited circles, but > the option is nice to have, especially if you want to support > virtual users under a single uid/gid. I was warning against typing the chroot too closely to a user's personal folders. Something like "/home" could still be useful as additional safety. I'd also like to see the daemon giving up some of its capabilities (*). Not being able to exec could be a nice protection - and I don't think bincimap needs it after initial setup, and shouldn't need it at all if executed post-authentication. (*) http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt [Speaking of capabilities, has anyone seen any wrapper programs which can drop specified capabilities, and then exec another program?] > This is good policy and doesn't restrict anyone to Maildir++. > Depending on your reading of http://cr.yp.to/proto/maildir.html, > maildir cannot contain other maildirs, My reading is that the given list are examples of things which may be found in a maildir. There's no claim that only items from that list may be found, and I know of no maildir capable programs which depend on there being no other files or directories contained in a maildir. > How do you propose dealing with non-folder/maildir subdirectories? If they are outside the tree that imapd cares about, they are ignored. If they are within that tree, then they are \Noselect folders if they ultimately contain a maildir, otherwise they are ignored. So every directory is either irrelevant, a maildir, or a component of the heirarchy containing a maildir. I think I gave an example directory tree, and how it would be seen by an IMAP client a few weeks ago. A tree walking function would call itself for each subdirectory, then list its own node if {new,cur,tmp} subdirectories exist, else list its own node \NoSelect if any of the subdirectory walks found anything, else return silently. -- Charlie
