On Fri, Aug 06, 2004 at 01:53:34PM +0200, Thomas Glanzmann wrote: > Hello Thomas, > > > And there we are in the middle of the reasons why I don't like the > > *maildir* header caching idea: Maildir is designed to be an NFS-safe > > mail folder format which actually works without explicit locking > > mechanisms. Adding database files that require explicit locking > > defeats this (big!) advantage of maildir. Keeping your mail on an NFS store is almost always a bad idea regardless of locking issues. If the user has root access to their workstation (which is often the case), then it is usually NOT POSSIBLE to secure the mail store against that user reading anyone's mail. Anyone at all, so long as they have permission to mount the filesystem which it is on. It also does not matter what permissions are on the directory, nor if the server uses the no_root_squash option or not. Assume /home is NFS exported. Simple exploit which will work in many, many environments: $ ls -ld /home/gooduser drwx--x--x 47 500 500 4096 Aug 6 22:29 /home/gooduser $ su - Password: # adduser -u 500 -g 500 -C "Bad Boy" -d /home/gooduser badboy # cd /home/gooduser Permission denied. # su - badboy [badboy@myhost /home/gooduser] $ less mbox ... This won't work if the environment uses Kerberos, or has NFS exports on a per-user basis, or users don't have root access to their machines. There may also be a few other mechanisms for authenticating NFS mounts on a per-user basis, similar to Kerberos. But the vast majority of real environments I know about would be (or would have been, in some cases where the company no longer exists) susceptible to this kind of attack. As for those locking issues, they also are more serious than most people realize. Due to NFS protocol limitations and/or problems with different vendors' implementations, here is NO LOCKING MECHANISM which works equally well over NFS on all platforms, or at least there wasn't as of about two years ago when I researched this issue extensively. If your environment is heterogenious, or your application has been written to use the one which happens not to work on your platform, then you will probably encounter locking issues. At one point, I'd looked into locking issues quite extensively. If memory serves, on some platforms, only the fcntl method actually works (usually via lockd and statd). According to a kernel developer friend of mine, this is the only method that works 100% reliably on Linux up to 2.4.x kernels. I don't remember why he said link() can fail, but he did. On others, you should use the link() system call, because lockd is broken. And while I think this is unlikely due to problems with the NFSv2 protocol design, on still others, it may be that only the O_EXCL|O_CREAT method of locking works. The details are unfortunately a big hazy now. So basically, locking over NFS is screwed from the get-go, unless your environment is homogenous and your app by coincidence uses the right locking method. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgpvhh9mMxLj4.pgp
Description: PGP signature