[exim] Re: locking et al.

Góra strony
Delete this message
Reply to this message
Autor: graeme vetterlein
Data:  
Dla: exim-users
Temat: [exim] Re: locking et al.
So, taking jgh@??? URL:
https://exim.org/exim-html-current/doc/html/spec_html/ch-the_appendfile_transport.html

I see the text:  (I've added **highlights**)



...Before appending to a file, a number of security checks are made, and
the file
is locked. A detailed description is given below, after the list of private
options.

...  The file option specifies a single file, to which the message is
 appended. One or more of use_fcntl_lock, use_flock_lock, or
use_lockfile must
 be set with file

...

use_fcntl_lock     Use: appendfile     Type: boolean Default: see below

This option controls the use of the fcntl() function to lock a file for
exclusive use when a message is being appended. **It is set by default
unless
use_flock_lock is set.**

So this is set by default UNLESS ...one of the other locking options is
chosen:

If I do:

root@ybox:/var/lib/exim4# grep -i use_ /var/lib/exim4/config.autogenerated
root@ybox:/var/lib/exim4# grep -i lock /var/lib/exim4/config.autogenerated
<no output>
And I note, I have in that same file:

mail_spool:
  debug_print = "T: appendfile for $local_part@$domain"
  driver = appendfile
  file = /var/mail/$local_part_data
  delivery_date_add
  envelope_to_add
  return_path_add
  group = mail
  mode = 0660
  mode_fail_narrower = false

So I take these together to mean:

   exim will use "apendfile" to append mail to /var/mail/<myuserid>
   and it will use fcntl(2) (I'm assuming advisory locking?)

So I (may need to) just ensure maildrop(1) also uses fcntl(2) locking

FYI, my concern is the end of one of my maildrop configs, which ends:

if ("$ADDRLIST" ne "")
   {
   log "@ in maildrop.manual $NOW, will send (using
/etc/maildroprc.manual) copies like this: $ADDRLIST [SENDMAIL=$SENDMAIL]"

# Spaces at the start really mess it up
    ADDRLIST=substr($ADDRLIST,1)
   to '!'"$ADDRLIST"
   }
else
   {
    log "@ in maildrop.manual $NOW, no routing found, will drop through
to DEFAULT=$DEFAULT"
   }

So if it uses [ to '!'"$ADDRLIST" ] then it will pass the message to
SMTP (aka
exim4) and exim4 will write to e.g. /var/mail/myuserid ... or if it drops
through, then maildrop will write to (the file) $DEFAULT, which could
well be
/var/mail/myuserid. Now I can't actually work out a case where 2
instances of
this could be running simultaneously, but I'm just nervous of two
different bits
of code writing to the same file. I'm reasonably confident exim4 would
protect
itself from another exim4 instance and likewise maildrop.

I think I'll go back to maildrop and see why I saw flock(2) getting used
an if
it can use fcntl(2) instead.

From maildrop:


--enable-use-flock=flag - if this option is set to 1, maildrop will use
either
  the flock(), the lockf(), or the fcntl() system call to lock a
mailbox file
  when delivering a message. **On most systems, all three use
compatible locking
  mechanisms.** In some very isolated cases, flock(), lockf(), and
fcntl(), are
  different, incompatible, locking mechanisms. maildrop must use the same
  locking mechanism as any mail reading programs. The configuration
script will
  run some tests to determine what locking function calls are
available, and
  will choose one by itself. The --with-locking-method can be used to
manually
  choose the locking function call to use.

--with-locking-method=name - manually select a locking function call.
name is
  either "fcntl", "flock", or "lockf". Otherwise the configuration
script will
  pick one by itself.

The comment there is somewhat at odds, to the flock(2) man page:

NOTES
       Since kernel 2.0, flock() is implemented as a system call  in 
its  own
       right  rather than being emulated in the GNU C library as a call
to fc‐
       ntl(2).  With this implementation, **there is no interaction
between  the
       types  of lock placed by flock() and fcntl(2),** and flock()
does not de‐
       tect deadlock.


... I'm probably worrying about nothing, this is a standard Debian
install and this same issue exists for Thunderbird, pine, mutt etc

so I suspect it was "sorted out" during the packaging.




--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/