Bug 113491

Is this still an issue in FC2?  Do you know of any solution, and
should we issue an update to FC1?

Seems to be fixed.

I take that back.  I hadn't actually selected the mailbox, so it
didn't print the error.  When I did, it failed just like before.

Dotlocking is the only universally reliable locking for mbox. If you
think it's not required in your system, set MBOX_LOCKS=fcntl
environment before running imap. I'm not going to change the defaults
or make Dovecot ignore the problem.

Some setuid dotlock helper which some other programs use might be
possible in future though.

Oh, except selecting the mbox in read-only state should be possible.
It probably fails because it tries to write UIDs in the mbox file, it
should rather fallback to read-only mode.. I'll make sure v1.0 works
this way.

Upstream dovecot shouldn't change the defaults, I agree, but if Fedora
Core ships with /var/mail's permissions set in such a way that only
group mail has write access, dovecot should by default work in such an
environment, so we need a Fedora-specific customization.  Getting only
read-only access to the mailbox with the default config would be quite
useless.

I just realized why I never ran into this problem.  I use INBOX within
each user's home directory.

I'm going over old bugs at the moment. I'm not I understand the
validity of this bug but perhaps my thinking is too narrow and I'm
missing a valid use case. Here are my thoughts, correct where you
think I'm off base.

* Running imap as an unprivileged user referencing files in a system
  wide spool directory is not a secure and wise scenario I'm inclined
  to invest time to support. Why is this valuable and sensible?

* The spool directory should be locked down and restricted. If you
  want unprivileged processes to have write access don't put the
  mailbox file in a system wide spool area, perhaps the users home
  directory makes a lot more sense if you want to run unprivileged
  processes. 

* Dovecot allows the specification of locking mechanisms, you can
  force dovecot to avoid dotlocks via dovecot's configuration
  file. However, after just doing a little experimentation and a very
  quick code review it appears that when you run just the imap process
  and short circuit the daemon the config file is not read. This of
  course brings me back to the question of why you're short circuiting
  the design, the authentication step, and why after doing so we
  should allow we should allow this in a system wide spool directory?

Sure, it would be nice if dovecot could operate in a "read-only" mode
and not by default attempt to creat dotlock files, but is the current
implementation and I feel like we need a justification for the
engineering time to fix this. What problem is running a dovecot
component in this very non-standard method solving? Why not start the
daemon, utilize authentication, and access the mail data via the imap
port? 

Timo, if I've gotten any of this wrong please jump in and correct me.

O.K. I've done more research into this and believe that dovecot has
configuration mechanisms available to eliminate the problem thus is is
a configuration and/or documentation issue, let me explain:

After authentication the imap process runs with the identity of the
authenticated user using his uid and gids. The mail spool directory is
"drwxrwxr-x root mail", only root and members of the group mail can
create files here, thus the imap process running with the privledges
of a normal user cannot create a dotlock.

There are several solutions if your MTA is doing local mail delivery
to a system spool directory instead of a per user defined location
(e.g. ~). Another solution is to disable dotlocks by setting the
configuration parameter mbox_locks to "fcntl" only, but this may be
ill adivsed depending on the filesystem.

The dovecot configuration file includes the following variable
"mail_extra_groups" which is a list of extra groups the user's imap
process can be made a member of. By default this list is empty, but in
the situation where the INBOX is in the spool directory and dotlocks
are being used then adding the group mail is an obvious choice. In
fact the documentation of the configuration parameters says:

    "Typical use would be to give "mail" group write access to
     /var/mail to be able to create dotlocks"

Another option would be to make sure mbox_read_dotlock is set to no
(it should be by default). However note, that if Timo is correct in
comment #5 that UID's are being written into the mbox file even during
just a read this maynot be sufficient because dotlocks may still be
created during the modification step, this I have not investigated.

However, if mail_extra_groups is set to include "mail" I believe the
whole issue disappears. I have verified this with testing in the
latest rev 0.99.13.

In summary I think this boiled down to ignorance of mail_extra_groups
variable and how it can be used in conjunction with a spool directory
containing an INBOX. It is true that granting a user imap process mail
group privledges opens some security vulnerabilities, but if that is a
true concern then don't locate the INBOX in the spool directory.

Well, the original problem seemed to be about running imap binary
directly. There can be some good uses for this, for example Pine can
use it by connecting to IMAP server via ssh.

For this the only solution to make it work would be to set imap binary
setgid-mail. Not a very good idea though, because users are able to
dynamically load modules..