[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The sad state of locking -> it almost works
From: |
Sergey Poznyakoff |
Subject: |
Re: The sad state of locking -> it almost works |
Date: |
Thu, 11 Apr 2002 13:06:52 +0300 |
Hi,
> that latest batch of changes to the locker doesn't really work. You can't
> silently change from a dot lock to a kernel lock and call it success. If
> some other program dotlocks it you will both think its locked.
This is possible, but consider this:
1. Default Linux /bin/mail uses flock to lock mailbox before writing
to it.
2. Widely-used (on GNU/Linux at least) mail.local uses both dot-lock
and kernel-level locking via flock.
3. Procmail (again widely used on GNU/Linux) creates dot-lock, but
uses flock before writing to the mailbox (see locking.c,
mailfold.c).
4. Mutt: first applies kernel locking, then creates dot-lock
if requested (see mx.c).
The overall situation confirms that the widely-used mail programs will
honour kernel locking.
> He won't realize it unless he loses some mail, or
> get suspicious when mail and some other program both have the same mailbox
> open for write
Basing on the above this doesn't seem probable.
> I only use QNX and Linux, and they use dotlocking, and their mail spools
> aren't writeable except by group mail,
Well, as for Linux this is not quite so. The 'dotlock vs. kernel
locking' situation is described above. Let's try to summarize
the information about mailspool permissions.
I. GNU/Linux:
(Debian):
drwxrwsr-x 2 root mail 18 Mar 28 20:46 /var/mail
(Slackware)
drwxrwxrwt 2 root mail 1024 Apr 11 11:58/var/spool/mail//
(SuSE)
drwxrwxrwt 2 root mail 1024 Apr 11 11:58/var/spool/mail//
II. Solaris/SunOS:
drwxrwxrwt 3 root mail 512 Apr 4 17:08 /var/mail
III. FreeBSD
drwxrwxr-x 2 bin mail 512 Jun 26 2001 /var/mail/
> So, requirements and proposals:
[..good stuff deleted..]
Seems ok. My proposals are to follow the practice shown by procmail,
mutt and others, that is: use dot-locking and apply kernel-locking
to the mailbox right before writing to it (of course, this applies
only to unix-style mailboxes).
> We agreed on adding the read/write lock flag back to locker_lock().
>
> - kernel locking can use it for rd/wr locks
>
> - utilities that wish can set a NO_LOCK_ON_READ flag (or it can
> be set in --lock-flags), it will do what it sounds like. Read
> locks will return sucessfully without actually locking.
OK.
> Alain and I talked about this a while. He convinced me that performance cost
> of dotlocking for utilities like frm is prohibitive.
Agreed.
> I think this covers all the normal cases. You mention that there
> is a third case for imap, a 3rd file location that neither the
> logged in user, nor the mail group has the ability to do locks in.
>
> Did you mean dotlocks, or kernel locks, or both?
Both, I believe. This happens when a mailbox to be read resides in a
non-writable directory and is non-writable itself. But then, there is
hardly a reason to lock it, is there?
> Is it possible that (4) above solves that? I.e., if they don't have
> access, they shouldn't do an IMAP "select", they should do an
> IMAP "examine", and that should mean that only read-only operations
> are performed on the mailbox. List should list the thing as read-only.
Surely, this will solve the problem with imap4d.
To summarize:
1. Introducing NO_LOCK_ON_READ solves problem with imap4d.
2. Problem with mail on systems whose mailspool is not world-writable
may be solved using setuid/setgid dotlock.
However, usual /bin/mail works without creating dotlock files, and
works quite reliably. So, consider my proposition about
compulsory kernel locking.
Regards,
Sergey
- The sad state of locking -> it almost works, Sam Roberts, 2002/04/11
- Re: The sad state of locking -> it almost works,
Sergey Poznyakoff <=
- Re: The sad state of locking -> it almost works, xystrus, 2002/04/11
- Re: The sad state of locking -> it almost works, Sergey Poznyakoff, 2002/04/12
- Re: The sad state of locking -> it almost works, xystrus, 2002/04/12
- Re: The sad state of locking -> it almost works, Alain Magloire, 2002/04/12
- Message not available
- Re: The sad state of locking -> it almost works, xystrus, 2002/04/14
- Re: The sad state of locking -> it almost works, Alain Magloire, 2002/04/22
Re: The sad state of locking -> it almost works, Sam Roberts, 2002/04/12