bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: intro


From: Sam Roberts
Subject: Re: intro
Date: Wed, 13 Mar 2002 20:38:54 -0500
User-agent: Mutt/1.3.16i

A few things:

- I very much want to know if there are any problems with locking
  over NFS other than that you have to do it right, using link().

I keep hearing about the notorious NFS locking problems... and it
seems to me its really a problem in a bunch of mail utilitis
that predate NFS and were never fixed. (Or maybe NFS should have
been fixed, but I don't have an opinion on that.)

Quoting xystrus <address@hidden>, who wrote:
> On Wed, Mar 13, 2002 at 02:16:10PM -0800, Jeff Bailey wrote:
> > On Wed, Mar 13, 2002 at 12:37:42PM -0500, xystrus wrote:
> > 
> > > If your users have root access to their machines, and you NFS 
> > > export the mail spool, you're giving them the ability to read the
> > > mail of anyone and everyone.  This is BAD.  
> > 
> > Only if you don't squash root.  People who don't follow sensible
> > sysadmin practices are not our problem.
> 
> Bzzzzz... sorry, but that's incorrect.  If I have root acces,
> all I need to do is su to another user whose mail is on the same
> spool.  Maybe I have to create the user first, but since I have
> root access, that's no problem.  Or if I'm in an NIS shop (ugh),
> I probably don't even have to do that.  And the best part is,
> since I'm root, I don't even need their password.
> 
> AFAIK the only solution for this is Kerberized NFS, which isn't
> terribly common, and AFAIK not yet available for Linux.

I don't know if Alain is right to say most people are accessing mailspools
over NFS, but even if NFS is insecure doesn't mean that doing this is,
does it?

If your pop/imap servers can see the NFS spools, that doesn't mean
that the clients of those servers can see the NFS traffic, you can
partition the traffic. Using NFS just seems a design choice.

Where I work, we'd fall into the category of 'if you have root you
can sniff network traffic', and anybody can get root on their linux
box by rebooting it into single user mode.

Of course, I can do that to yours as well, and install some cool kernel
module that hides itself and sniffs your passwords, so I don't need
to sniff NFS to compromise your mail.

Anyhow, we're off into deepening circles of paranoia. And nobody is
being forced to use NFS!


> > > I've seen NFS-mounted spools result in lost mail before...  it's
> > > just a bad idea, IMO.
> > 
> > I think maildir is supposed to handle locking over NFS correctly.
> 
> Sure, as I understand it maildir basically needs no locking.  Is
> that correct?  I still haven't had a chance to read up on it...

Yes. It's one file per message, so you don't have to lock to delete
messages. To create messages you create them with a unique name (much
like you have to dotlock over NFS) and link them to their final name.

The other reason to modify messages is to modify the message flags.
You don't have to lock with Maildir because the message flags are appended
to the filename, and you link a message to a new filename to change
the flags.

All from memory, but I read up on this a few weeks ago.

And I'm on the mutt-dev mailiing list, too. The things servers do
to mailspools may be faster with Maildir (that's what the courier
benchmark looked at), but what MUAs do, indexing, sorting, displaying
number of lines, etc. looks like it can be slower when the messages
are spread through a bunch of files. Like many things, you have to
trade off.

I think mutt has some people working on keeping a cache of the
message meta-information... but I guess they'll have to lock access
to the cache. Oh well, c'est la vie!

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]