← Back to branch summary

~ubuntu-branches/debian/stretch/alpine/stretch

« back to all changes in this revision

Viewing changes to imap/docs/locking.txt

  • Committer: Bazaar Package Importer
  • Author(s): Asheesh Laroia
  • Date: 2007-02-17 13:17:42 UTC
  • Revision ID: james.westby@ubuntu.com-20070217131742-c5pt3x6wk9djgcxy
Tags: 0.82+dfsg-5
Actually make pilot "priority: optional".

Show diffs side-by-side

added added

removed removed

Lines of Context:
imap/docs/locking.txt
255
255
timeout for this lock, after which it is broken on the presumption
256
256
that it is a stale lock.  If it can not create the .lock file due to
257
257
an EACCES (protection failure) error, it once silently proceeded
258
 
without this lock; this was for systems which protect /usr/spool/mail
 
258
without this lock; this was for systems which protect /var/mail
259
259
from unprivileged processes creating files.  Today, c-client reports
260
260
an error unless it is built otherwise.  The purpose of this lock is to
261
261
prevent against unfavorable interactions with mail delivery.
278
278
 
279
279
     Mail delivery daemons use lock (1), (2), or both.  Lock (1) works
280
280
over NFS; lock (2) is the only one that works on sites that protect
281
 
/usr/spool/mail against unprivileged file creation.  Prudent mail
 
281
/var/mail against unprivileged file creation.  Prudent mail
282
282
delivery daemons use both forms of locking, and of course so does
283
283
c-client.
284
284
 
335
335
the mail file is NFS-mounted.
336
336
 
337
337
     What this means is that there is *no* locking protection at all
338
 
in the case of a client using an NFS-mounted /usr/spool/mail that does
 
338
in the case of a client using an NFS-mounted /var/mail that does
339
339
not permit file creation by unprivileged programs.  It is impossible,
340
340
under these circumstances, for an unprivileged program to do anything
341
341
about it.  Worse, if EACCES errors on .lock file creation are no-op'ed