[Dovecot] Restoring individual messages from a backup into a Maildir setup?
We have a user who deleted IMAP folders from his account, so I simply tried to restore the folder ".FolderName" from our backup. I checked that file/folder ownership was the same as the original, but the Dovecot IMAP server is throwing errors at the client.
I've tried copying the individual message files from the "cur" folders in the backup directory, but Dovecot immediate goes into panic mode and throws errors at the IMAP client when I do that. Even if the file is owned by the currect UID. I've tried putting those files into "tmp" and "new" as well, with no luck.
I looked at the following thread, but it didn't help.
http://www.dovecot.org/list/dovecot/2007-August/024971.html
The thread from Sep 2008 wasn't much help either:
http://www.mail-archive.com/dovecot@dovecot.org/msg12846.html
...
Eh, I figured this out before I even posted. Restoration is indeed that simple. The problem is that the files were not labeled with the proper SELinux security context after being restored. When the file was restored, it was assigned a context of "root:object_r:file_t", which is not a context that the Dovecot service has permissions to interact with.
I had to re-label the files after restoring them with
# chcon -R user_u:object_r:mail_spool_t foldername
So the lesson here is to check /var/log/messages and look for sealert indicators when restoring files.
...
Hopefully that helps some other people out when dealing with Red Hat / CentOS with SELinux set to enforcing mode.
On Thu, 2009-01-08 at 15:36 -0500, Thomas Harold wrote:
We have a user who deleted IMAP folders from his account, so I simply tried to restore the folder ".FolderName" from our backup. I checked that file/folder ownership was the same as the original, but the Dovecot IMAP server is throwing errors at the client.
I've tried copying the individual message files from the "cur" folders in the backup directory, but Dovecot immediate goes into panic mode and throws errors at the IMAP client when I do that. Even if the file is owned by the currect UID. I've tried putting those files into "tmp" and "new" as well, with no luck. .. Eh, I figured this out before I even posted. Restoration is indeed that simple. The problem is that the files were not labeled with the proper SELinux security context after being restored. When the file was restored, it was assigned a context of "root:object_r:file_t", which is not a context that the Dovecot service has permissions to interact with.
What was it logging? I think it should have clearly said there about permission errors.
Timo Sirainen wrote:
On Thu, 2009-01-08 at 15:36 -0500, Thomas Harold wrote:
We have a user who deleted IMAP folders from his account, so I simply tried to restore the folder ".FolderName" from our backup. I checked that file/folder ownership was the same as the original, but the Dovecot IMAP server is throwing errors at the client.
I've tried copying the individual message files from the "cur" folders in the backup directory, but Dovecot immediate goes into panic mode and throws errors at the IMAP client when I do that. Even if the file is owned by the currect UID. I've tried putting those files into "tmp" and "new" as well, with no luck. .. Eh, I figured this out before I even posted. Restoration is indeed that simple. The problem is that the files were not labeled with the proper SELinux security context after being restored. When the file was restored, it was assigned a context of "root:object_r:file_t", which is not a context that the Dovecot service has permissions to interact with.
What was it logging? I think it should have clearly said there about permission errors.
Oh, all sorts of errors in /var/log/messages:
Jan 8 14:48:59 fvs-pri setroubleshoot: SELinux is preventing access to files with the label, file_t. For complete SELinux messages. run sealert -l 8e0628b1-d30a-4390-8364-a899e0d1162b
Jan 8 15:25:42 fvs-pri setroubleshoot: SELinux is preventing imap (dovecot_t) "getattr" to /var/vmail/domain/username/dovecot.index.log (var_t). For complete SELinux messages. run sealert -l 05bc0c54-dedf-4a0b-a1ee-072b2f46ca88
Jan 8 15:27:16 fvs-pri setroubleshoot: SELinux is preventing imap (dovecot_t) "write" to ./cur (var_t). For complete SELinux messages. run sealert -l d8ecb97c-4f3e-454a-bc40-97f1c6a3dc0a
Jan 8 15:27:16 fvs-pri setroubleshoot: SELinux is preventing imap (dovecot_t) "read write" to ./dovecot.index.log (var_t). For complete SELinux messages. run sealert -l 5e4fd55f-401e-4ec1-ab7a-53fd9d4e09c1
Jan 8 15:27:16 fvs-pri setroubleshoot: SELinux is preventing imap (dovecot_t) "read write" to ./dovecot-uidlist (var_t). For complete SELinux messages. run sealert -l b58a00ab-7182-4a35-af92-3ebf1eb4fbb3
Jan 8 15:27:22 fvs-pri setroubleshoot: SELinux is preventing imap (dovecot_t) "read write" to ./dovecot-uidlist (var_t). For complete SELinux messages. run sealert -l b58a00ab-7182-4a35-af92-3ebf1eb4fbb3
...
My first inclination was to look at the dovecot-deliver.log file (per log_path or info_log_path). It wasn't until I went looking for SELinux errors that I discovered that it was a labeling problem.
Just a standard PEBKAC error.
On Thu, 2009-01-08 at 16:35 -0500, Thomas Harold wrote:
What was it logging? I think it should have clearly said there about permission errors.
Oh, all sorts of errors in /var/log/messages:
Jan 8 14:48:59 fvs-pri setroubleshoot: SELinux is preventing access to files with the label, file_t. For complete SELinux messages. run sealert -l 8e0628b1-d30a-4390-8364-a899e0d1162b .. My first inclination was to look at the dovecot-deliver.log file (per log_path or info_log_path). It wasn't until I went looking for SELinux errors that I discovered that it was a labeling problem.
That's what I meant, did Dovecot not log anything?
Timo Sirainen wrote:
On Thu, 2009-01-08 at 16:35 -0500, Thomas Harold wrote:
What was it logging? I think it should have clearly said there about permission errors.
Oh, all sorts of errors in /var/log/messages:
Jan 8 14:48:59 fvs-pri setroubleshoot: SELinux is preventing access to files with the label, file_t. For complete SELinux messages. run sealert -l 8e0628b1-d30a-4390-8364-a899e0d1162b .. My first inclination was to look at the dovecot-deliver.log file (per log_path or info_log_path). It wasn't until I went looking for SELinux errors that I discovered that it was a labeling problem.
That's what I meant, did Dovecot not log anything?
None that I could find. At 14:48, there's nothing in the dovecot-deliver.log file (set in the "protocol lda" section of our dovecot.conf).
But our logging section at the top of the dovecot.conf file is:
## ## Logging ##
# Log file to use for error messages, instead of sending them to syslog. # /dev/stderr can be used to log into stderr. #log_path = /var/log/dovecot.log
# Log file to use for informational and debug messages. # Default is the same as log_path. #info_log_path =
So I'm not sure that is configured correctly to actually log errors.
Currently running dovecot.x86_64 1:1.1.6-0_83.el5 from atrpms. We'll probably upgrade to 1.1.7 soon (a manual process for us since we're doing maildir delivery with separate userids and a setuid executable).
Thomas Harold wrote:
Timo Sirainen wrote:
That's what I meant, did Dovecot not log anything
None that I could find. At 14:48, there's nothing in the dovecot-deliver.log file (set in the "protocol lda" section of our dovecot.conf).
I believe Timo is asking for information on the main log (of dovecot itself and its login, imap and pop processes). From what I understand of your scenario, deliver has nothing to do with the restored messages.
-- Eduardo M KALINOWSKI eduardo@kalinowski.com.br http://move.to/hpkb
On Thu, 2009-01-08 at 17:02 -0500, Thomas Harold wrote:
My first inclination was to look at the dovecot-deliver.log file (per log_path or info_log_path). It wasn't until I went looking for SELinux errors that I discovered that it was a labeling problem.
That's what I meant, did Dovecot not log anything?
None that I could find. At 14:48, there's nothing in the dovecot-deliver.log file (set in the "protocol lda" section of our dovecot.conf).
Well, that logs only deliver's errors.
But our logging section at the top of the dovecot.conf file is:
## ## Logging ##
# Log file to use for error messages, instead of sending them to syslog. # /dev/stderr can be used to log into stderr. #log_path = /var/log/dovecot.log
# Log file to use for informational and debug messages. # Default is the same as log_path. #info_log_path =
So I'm not sure that is configured correctly to actually log errors.
They get logged to syslog, which probably goes to mail.log or something like that.
Timo Sirainen wrote:
They get logged to syslog, which probably goes to mail.log or something like that.
Got it, buried in among the postfix log information in our maillog.
Jan 8 14:48:36 fvs-pri dovecot: IMAP(frank@nybeta.com): open(/var/vmail/domain/username/.foldername/cur/1221150263.M565639P 20403.fvs-pri.example.com,W=7199:2,S) failed: Permission denied
Jan 8 14:48:36 fvs-pri dovecot: IMAP(frank@nybeta.com): stat(/var/vmail/domain/username/.foldername/cur/1221150263.M565639P 20403.fvs-pri.example.com,W=7199:2,S) failed: Permission denied
Jan 8 14:48:36 fvs-pri dovecot: IMAP(username@example.com): Disconnected: Internal error occurred. Refer to server log for more information. [2009-01-08 14:48:36] bytes=845/3222
participants (3)
-
Eduardo M KALINOWSKI
-
Thomas Harold
-
Timo Sirainen