Bug 113491 - dovecot preauth imap fails attempting to dotlock mailbox
dovecot preauth imap fails attempting to dotlock mailbox
Product: Fedora
Classification: Fedora
Component: dovecot (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: John Dennis
Depends On:
  Show dependency treegraph
Reported: 2004-01-14 11:58 EST by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version: dovecot-
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-13 14:09:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2004-01-14 11:58:39 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031202

Description of problem:
In a default install of Fedora Core 1, /var/spool/mail is writable
only by root and group mail.  If a user that is not member of group
mail runs /usr/libexec/dovecot/imap, for preauth imap access to the
mailbox, it fails with a hard error.

Florian La Roche says it's ok for it to attempt to dotlock, but
Notting argues it shouldn't fail if dotlocking fails.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Run /usr/libexec/dovecot/imap as a user that is not root nor member
of group mail, making sure /var/spool/mail is not writable by all (it
isn't by default)

LIST-SUBSCRIBED] Logged in as aoliva
0 select INBOX
imap(aoliva): Error: open(/var/spool/mail/aoliva.lock) failed:
Permission deniedimap(aoliva): Error: file_lock_dotlock() failed with
mbox file /var/spool/mail/aoliva: Permission denied
imap(aoliva): Error: open(/var/spool/mail/aoliva.lock) failed:
Permission deniedimap(aoliva): Error: file_lock_dotlock() failed with
mbox file /var/spool/mail/aoliva: Permission denied
0 NO Internal error [2004-01-12 17:06:26]

Expected Results:  It shouldn't fail to select the mailbox.

Additional info:
Comment 1 Warren Togami 2004-05-19 06:23:52 EDT
Is this still an issue in FC2?  Do you know of any solution, and
should we issue an update to FC1?
Comment 2 Alexandre Oliva 2004-05-19 07:43:24 EDT
Seems to be fixed.
Comment 3 Alexandre Oliva 2004-05-20 18:55:09 EDT
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.
Comment 4 Timo Sirainen 2004-05-21 21:27:06 EDT
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.
Comment 5 Timo Sirainen 2004-05-21 21:35:22 EDT
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.
Comment 6 Alexandre Oliva 2004-05-22 01:40:28 EDT
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
Comment 7 Warren Togami 2004-05-22 02:07:21 EDT
I just realized why I never ran into this problem.  I use INBOX within
each user's home directory.
Comment 8 John Dennis 2005-01-05 14:49:59 EST
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

* 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
Comment 9 John Dennis 2005-01-13 14:09:18 EST
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.
Comment 10 Timo Sirainen 2005-01-13 15:31:08 EST
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..

Note You need to log in before you can comment on or make changes to this bug.