On Wed, 8 Nov 2006, Dan Mahoney, System Admin wrote:
Yay! I had been following this issue with some trepidation, as my situation is that I want to get USER shell processes (like pine) OFF of the main server where delivery happens, as pine can get kinda hungry when munching and searching large mailboxes (mine currently shows a 60 meg footprint in top), and imap may still be attempting to access the mailbox from the NFS server end, while pine would be accessing it from an NFS client machine.
The good news for you is that NFS is alright for SHELL user mailbox files in traditional UNIX mailbox format, but not for mbx and mix.
The reason why it's alright for shell users, and not for IMAP, is that shell users generally do not hit their mailbox files with multiple MUA programs (such as Pine) at the same time. In the rare instances when they do, it is generally when they run an MUA at a new location even though they left one running at the old location. The c-client library's "kiss of death" mechanism is explicitly for this scenario.
IMAP clients, on the other hand, frequently invoke multiple sessions to the same mailbox simultaneously. This is what causes the problems.
Other than the fact that another user can create their own lock files for all users? Or does file ownership somehow count with dotlocks, i.e. that the system will ignore the lockfile if it's not owned by the same uid as the file being locked?
If you use a spool directory, you are basically in a cooperative environment.
If the spool directory is protected against file creation, then that means that only privileged agents can create lock files. This is a double-edged sword. Some MUAs run privileged, which means that any bug in that MUA opens up the access granted by those privileges. Remember that MUA programs are very large; the larger the program the greater the vulnerability risk.
Pine does not run with privileges. If it has to use a privileged agent to create a lock, it tries calling the mlock tool (part of UW IMAP). mlock is designed to be a very small, easy-to-audit program. The bad thing about running mlock...is that you have to run mlock; it's an additional complication and point where something can go wrong.
Now, let's talk about "cooperative environment" with a spool directory. The usual arguments advanced against it is that you may have users who are not trustworthy, and thus need to be restrained. Many sites have that problem. Some sites, such as family site, probably do not.
However, assuming that you have untrustworthy users, you have other problems with a shared spool directory. The ability to do a stat() of other users' mailbox files gives you the ability to monitor (read: cyberstalk) that other user's volume of incoming mail and when that person last read mail. You may be legally required to close that loophole!
Next, if you have a large user community, do you really want a single directory with 10,000...100,000...1,000,000 files in it??
My opinion is that a spool directory is only suitable for a small, intimate user community where a "cooperative environment" is alright; and that if you don't have that you are better off delivering mail directly to a directory owned by the recipient user.
I provide the mlock tool for those sites that feel that they have greater security needs than the small, intimate, cooperative environment; but do not want to go to delivery of mail to a directory owned by the recipient. I would never run a system that way; so I would never use mlock.
-- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
