dovecot - Jan 2009 - 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 at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090108/090f3629/attachment-0002.bin>

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.