oddity with postfix delivering to homedir

[Manuel Wolfshant]

hello

    I have migrated a working mailserver from Centos 4.7 to Centos 5.2. 
The system uses postfix to receive messages from a mail relay and is 
supposed to deliver them to  folders named after the users, following 
the /home/firstname.lastname@domain template. Authentication is done via 
mysql against a db running on another system.
    New accounts are created automatically when a mail has to be 
delivered to an user which has never been seen before.
    For the users which existed before migration, everything is fine. 
However, for non-existing (i.e. to be created) users the homedir is 
created with wrong contexts, which prohibit postfix to finalize the 
delivery. Once a message is received for a new user, the following is 
created:

    [root@imap2 ~]# ll -Zl /home/gigi.test\(a)nobugconsulting.ro/ -R
/home/gigi.test(a)nobugconsulting.ro/:                          
total 8                                                       
drwx------ 2 root:object_r:home_root_t        postfix postfix 4096 Feb 
17 01:05 tmp

/home/gigi.test(a)nobugconsulting.ro/tmp:
total 4                               
-rw------- 1 root:object_r:home_root_t        postfix postfix 0 Feb 17 
01:05 1234825528.P26797.imap2

    After that postfix tries to do stuff on the newly created file and 
selinux kicks in and denies access.
    Running restorecon at this point fixes things:

    [root@imap2 ~]# restorecon -v -R 
/home/gigi.test(a)nobugconsulting.ro                                
restorecon reset /home/gigi.test(a)nobugconsulting.ro context 
root:object_r:home_root_t:s0->user_u:object_r:user_home_dir_t:s0
restorecon reset /home/gigi.test(a)nobugconsulting.ro/tmp context 
root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0
restorecon reset 
/home/gigi.test(a)nobugconsulting.ro/tmp/1234825528.P26797.imap2 context 
root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0                     



    I am running the following versions of packages:

[root@imap2 ~]# rpm -qa kernel\* \*selinux\* postfix\*
kernel-xen-2.6.18-92.1.22.el5
libselinux-utils-1.33.4-5.1.el5
selinux-policy-targeted-2.4.6-203.el5
libselinux-1.33.4-5.1.el5
libselinux-python-1.33.4-5.1.el5
selinux-policy-2.4.6-203.el5
postfix-2.3.3-2.1.centos.mysql_pgsql

    Selinux related packages have been upgraded last night in the hope 
to fix the problem, postfix is almost stock centosplus 5.2, recompiled 
with support for mysql but without postgresql- support.

    Obviously I no not want to follow the result of  audit2allow, 
home_root_t:dir should not be there in the first place:
[root@imap2 ~]# grep avc /var/log/audit/audit.log|audit2allow

#============= postfix_virtual_t ==============
allow postfix_virtual_t home_root_t:dir { write remove_name create 
add_name };
allow postfix_virtual_t home_root_t:file { write create unlink link 
getattr };
allow postfix_virtual_t postfix_private_t:dir search;
allow postfix_virtual_t postfix_private_t:sock_file write;
allow postfix_virtual_t usr_t:file { read getattr };

    Correct access rights and contexts seem to be:
[root@imap2 ~]# ls -l /home/ -dZ
drwxr-xr-x+ postfix postfix system_u:object_r:home_root_t    /home/
[root@imap2 ~]# ls -l /home/gigi.test\(a)nobugconsulting.ro/ -dZ
drwx------  postfix postfix user_u:object_r:user_home_dir_t  
/home/gigi.test(a)nobugconsulting.ro/

    The only user on the system (beside root) is postfix:
[root@imap2 ~]# getent passwd postfix
postfix:x:89:89::/var/spool/postfix:/sbin/nologin

    raw content of audit log after a failed delivery for a never-seen 
before user:
type=AVC msg=audit(1234873447.682:45616): avc:  denied  { write } for  
pid=2958 comm="virtual" 
path="/home/gigi.test(a)nobugconsulting.ro/tmp/1234873447.P2958.imap2" 
dev=hda1 ino=2736137 scontext=root:system_r:postfix_virtual_t:s0 
tcontext=root:object_r:home_root_t:s0 tclass=file
type=SYSCALL msg=audit(1234873447.682:45616): arch=c000003e syscall=1 
success=no exit=-13 a0=c a1=2b96176fe510 a2=1b5 a3=7228206f722e676e 
items=0 ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 
egid=89 sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual" 
exe="/usr/libexec/postfix/virtual" 
subj=root:system_r:postfix_virtual_t:s0 key=(null)
type=AVC msg=audit(1234873447.710:45617): avc:  denied  { write } for  
pid=2958 comm="virtual" name="1234873447.P2958.imap2" dev=hda1 
ino=2736137 scontext=root:system_r:postfix_virtual_t:s0 
tcontext=root:object_r:home_root_t:s0 tclass=file
type=SYSCALL msg=audit(1234873447.710:45617): arch=c000003e syscall=77 
success=no exit=-13 a0=c a1=0 a2=2 a3=0 items=0 ppid=26787 pid=2958 
auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89 sgid=0 fsgid=89 
tty=(none) ses=7290 comm="virtual" exe="/usr/libexec/postfix/virtual"

subj=root:system_r:postfix_virtual_t:s0 key=(null)
type=AVC msg=audit(1234873447.710:45618): avc:  denied  { remove_name } 
for  pid=2958 comm="virtual" name="1234873447.P2958.imap2" 
dev=hda1ino=2736137 scontext=root:system_r:postfix_virtual_t:s0 
tcontext=root:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1234873447.710:45618): arch=c000003e syscall=87 
success=no exit=-13 a0=2b96176fdb80 a1=64 a2=4 a3=2b95fb0340ec items=0 
ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89 
sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual" 
exe="/usr/libexec/postfix/virtual" 
subj=root:system_r:postfix_virtual_t:s0 key=(null)






    My questions are
a) why does postfix create the initial home directories with a wrong 
context ? Note this only happens for NEW users, messages for the users 
which already existed [and have correct context] on the old system are 
perfectly fine.
b) what can I do to fix ?



    Tia
        Manuel

[Dominick Grift]

On Tue, 2009-02-17 at 14:27 +0200, Manuel Wolfshant wrote:

>      My questions are
>  a) why does postfix create the initial home directories with a wrong 
>  context ? Note this only happens for NEW users, messages for the users 
>  which already existed [and have correct context] on the old system are 
>  perfectly fine. 
I think it has to do with the way genhomedircon works. Since postfix is
the owner and is a system account. I am not sure. Hopefully someone else
can shed some light on this.

>  b) what can I do to fix ? 
I think that restorecond should fix this. Is it running? and is /home
added to restorecond.conf?

>  
>  
>      Tia
>          Manuel
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manuel Wolfshant wrote:
>  hello
>  
>     I have migrated a working mailserver from Centos 4.7 to Centos 5.2.
>  The system uses postfix to receive messages from a mail relay and is
>  supposed to deliver them to  folders named after the users, following
>  the /home/firstname.lastname@domain template. Authentication is done via
>  mysql against a db running on another system.
>     New accounts are created automatically when a mail has to be
>  delivered to an user which has never been seen before.
>     For the users which existed before migration, everything is fine.
>  However, for non-existing (i.e. to be created) users the homedir is
>  created with wrong contexts, which prohibit postfix to finalize the
>  delivery. Once a message is received for a new user, the following is
>  created:
>  
>     [root@imap2 ~]# ll -Zl /home/gigi.test\(a)nobugconsulting.ro/ -R
>  /home/gigi.test(a)nobugconsulting.ro/:                          total
>  8                                                       drwx------ 2
>  root:object_r:home_root_t        postfix postfix 4096 Feb 17 01:05 tmp
>  
>  /home/gigi.test(a)nobugconsulting.ro/tmp:
>  total 4                               -rw------- 1
>  root:object_r:home_root_t        postfix postfix 0 Feb 17 01:05
>  1234825528.P26797.imap2
>  
>     After that postfix tries to do stuff on the newly created file and
>  selinux kicks in and denies access.
>     Running restorecon at this point fixes things:
>  
>     [root@imap2 ~]# restorecon -v -R
>  /home/gigi.test(a)nobugconsulting.ro                               
>  restorecon reset /home/gigi.test(a)nobugconsulting.ro context
>  root:object_r:home_root_t:s0->user_u:object_r:user_home_dir_t:s0
>  restorecon reset /home/gigi.test(a)nobugconsulting.ro/tmp context
>  root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0
>  restorecon reset
>  /home/gigi.test(a)nobugconsulting.ro/tmp/1234825528.P26797.imap2 context
>  root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0                    
>  
>  
>  
>     I am running the following versions of packages:
>  
>  [root@imap2 ~]# rpm -qa kernel\* \*selinux\* postfix\*
>  kernel-xen-2.6.18-92.1.22.el5
>  libselinux-utils-1.33.4-5.1.el5
>  selinux-policy-targeted-2.4.6-203.el5
>  libselinux-1.33.4-5.1.el5
>  libselinux-python-1.33.4-5.1.el5
>  selinux-policy-2.4.6-203.el5
>  postfix-2.3.3-2.1.centos.mysql_pgsql
>  
>     Selinux related packages have been upgraded last night in the hope to
>  fix the problem, postfix is almost stock centosplus 5.2, recompiled with
>  support for mysql but without postgresql- support.
>  
>     Obviously I no not want to follow the result of  audit2allow,
>  home_root_t:dir should not be there in the first place:
>  [root@imap2 ~]# grep avc /var/log/audit/audit.log|audit2allow
>  
>  #============= postfix_virtual_t ==============
>  allow postfix_virtual_t home_root_t:dir { write remove_name create
>  add_name };
>  allow postfix_virtual_t home_root_t:file { write create unlink link
>  getattr };
>  allow postfix_virtual_t postfix_private_t:dir search;
>  allow postfix_virtual_t postfix_private_t:sock_file write;
>  allow postfix_virtual_t usr_t:file { read getattr };
>  
>     Correct access rights and contexts seem to be:
>  [root@imap2 ~]# ls -l /home/ -dZ
>  drwxr-xr-x+ postfix postfix system_u:object_r:home_root_t    /home/
>  [root@imap2 ~]# ls -l /home/gigi.test\(a)nobugconsulting.ro/ -dZ
>  drwx------  postfix postfix user_u:object_r:user_home_dir_t 
>  /home/gigi.test(a)nobugconsulting.ro/
>  
>     The only user on the system (beside root) is postfix:
>  [root@imap2 ~]# getent passwd postfix
>  postfix:x:89:89::/var/spool/postfix:/sbin/nologin
>  
>     raw content of audit log after a failed delivery for a never-seen
>  before user:
>  type=AVC msg=audit(1234873447.682:45616): avc:  denied  { write } for 
>  pid=2958 comm="virtual"
>  path="/home/gigi.test(a)nobugconsulting.ro/tmp/1234873447.P2958.imap2"
>  dev=hda1 ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
>  tcontext=root:object_r:home_root_t:s0 tclass=file
>  type=SYSCALL msg=audit(1234873447.682:45616): arch=c000003e syscall=1
>  success=no exit=-13 a0=c a1=2b96176fe510 a2=1b5 a3=7228206f722e676e
>  items=0 ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89
>  egid=89 sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual"
>  exe="/usr/libexec/postfix/virtual"
>  subj=root:system_r:postfix_virtual_t:s0 key=(null)
>  type=AVC msg=audit(1234873447.710:45617): avc:  denied  { write } for 
>  pid=2958 comm="virtual" name="1234873447.P2958.imap2" dev=hda1
>  ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
>  tcontext=root:object_r:home_root_t:s0 tclass=file
>  type=SYSCALL msg=audit(1234873447.710:45617): arch=c000003e syscall=77
>  success=no exit=-13 a0=c a1=0 a2=2 a3=0 items=0 ppid=26787 pid=2958
>  auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89 sgid=0 fsgid=89
>  tty=(none) ses=7290 comm="virtual"
> exe="/usr/libexec/postfix/virtual"
>  subj=root:system_r:postfix_virtual_t:s0 key=(null)
>  type=AVC msg=audit(1234873447.710:45618): avc:  denied  { remove_name }
>  for  pid=2958 comm="virtual" name="1234873447.P2958.imap2"
>  dev=hda1ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
>  tcontext=root:object_r:home_root_t:s0 tclass=dir
>  type=SYSCALL msg=audit(1234873447.710:45618): arch=c000003e syscall=87
>  success=no exit=-13 a0=2b96176fdb80 a1=64 a2=4 a3=2b95fb0340ec items=0
>  ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89
>  sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual"
>  exe="/usr/libexec/postfix/virtual"
>  subj=root:system_r:postfix_virtual_t:s0 key=(null)
>  
>  
>  
>  
>  
>  
>     My questions are
>  a) why does postfix create the initial home directories with a wrong
>  context ? Note this only happens for NEW users, messages for the users
>  which already existed [and have correct context] on the old system are
>  perfectly fine. 
Does postfix actually create the homedir or was the homedir created
by
an init script?  postfix does not know anything about SELinux but there
are rules about processes running as postfix_t creating files in
user_home_dir_t directories.  In your case it seems that the directory
was labeled home_root_t, which is where the problem is.

>  b) what can I do to fix ?
>   
The restorecon should have fixed the homedir problem, the other policy I
will add to the 5.4 update.

selinux-policy-2.4.6-213.el5  Should be up on
http://people.redhat.com/dwalsh/RHEL5/

Soon
>  
>  
>     Tia
>         Manuel
>  
>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmavHwACgkQrlYvE4MpobNM1ACfRZ0r/ktrvdHzznz0gNF29u9M
> x1AAn1LzsHhjGoYiAPzF6XH80ONZAXoD
> =zInN
> -----END PGP SIGNATURE-----

[Manuel Wolfshant]

Dominick Grift wrote:
>  On Tue, 2009-02-17 at 14:27 +0200, Manuel Wolfshant wrote:
>
>    
> >     My questions are
> > a) why does postfix create the initial home directories with a wrong 
> > context ? Note this only happens for NEW users, messages for the users 
> > which already existed [and have correct context] on the old system are 
> > perfectly fine.
> >     
>
>  I think it has to do with the way genhomedircon works. Since postfix is
>  the owner and is a system account. I am not sure. Hopefully someone else
>  can shed some light on this.
>
>    
> > b) what can I do to fix ?
> >     
>
>  I think that restorecond should fix this. Is it running? and is /home
>  added to restorecond.conf?
>     
restorecond was (and is) running. /home was not included in restorecond.conf, but even
after adding it (and reload/restart /etc/init.d/restorecond) there is no change

As additional info, /var/log/messages has:
Feb 17 15:30:12 imap2 setroubleshoot: SELinux is preventing virtual (postfix_virtual_t)
"write" to /home/gigi.test(a)nobugconsulting.ro/tmp/1234877410.P4488.imap2
(home_root_t). For complete SELinux messages. run sealert -l
0bc7c6e1-96d8-4f59-bcac-a11fbc699e2a
Feb 17 15:30:12 imap2 setroubleshoot: SELinux is preventing virtual (postfix_virtual_t)
"remove_name" to ./1234877410.P4488.imap2 (home_root_t). For complete SELinux
messages. run sealert -l 51b63565-8a4d-494e-808b-d235cbdd5683
Feb 17 15:30:12 imap2 setroubleshoot: SELinux is preventing virtual (postfix_virtual_t)
"write" to ./1234877410.P4488.imap2 (home_root_t). For complete SELinux
messages. run sealert -l 54d85276-b21c-4753-9937-afb48373c326

not surprisingly, sealert -l gives "SELinux is preventing virtual (postfix_virtual_t)
"write" to /home/gigi.test(a)nobugconsulting.ro/tmp/1234877410.P4488.imap2
(home_root_t)."

Additional Information:

Source Context                root:system_r:postfix_virtual_t
Target Context                root:object_r:home_root_t
Target Objects                /home/gigi.test(a)nobugconsulting.ro/tmp/1234877410.
                              P4488.imap2 [ file ]
Source                        virtual
Source Path                   /usr/libexec/postfix/virtual
Port                          <Unknown>
Host                          imap2
Source RPM Packages           postfix-2.3.3-2.1.centos.mysql_pgsql
Target RPM Packages
Policy RPM                    selinux-policy-2.4.6-203.el5
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   catchall_file
Host Name                     imap2
Platform                      Linux imap2 2.6.18-92.1.22.el5xen #1 SMP Tue Dec
                              16 12:26:32 EST 2008 x86_64 x86_64
Alert Count                   1
First Seen                    Tue Feb 17 15:30:10 2009
Last Seen                     Tue Feb 17 15:30:10 2009
Local ID                      0bc7c6e1-96d8-4f59-bcac-a11fbc699e2a
Line Numbers

Raw Audit Messages

host=imap2 type=AVC msg=audit(1234877410.37:45680): avc:  denied  { write } for  pid=4488
comm="virtual"
path=&quot;/home/gigi.test(a)nobugconsulting.ro/tmp/1234877410.P4488.imap2&quot; dev=hda1
ino=29982723 scontext=root:system_r:postfix_virtual_t:s0
tcontext=root:object_r:home_root_t:s0 tclass=file

host=imap2 type=SYSCALL msg=audit(1234877410.37:45680): arch=c000003e syscall=1 success=no
exit=-13 a0=c a1=2b06b8c9f520 a2=1b5 a3=7228206f722e676e items=0 ppid=26787 pid=4488
auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89 sgid=0 fsgid=89 tty=(none) ses=7290
comm="virtual" exe="/usr/libexec/postfix/virtual"
subj=root:system_r:postfix_virtual_t:s0 key=(null)

[Manuel Wolfshant]

Daniel J Walsh wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  Manuel Wolfshant wrote:
>    
> > hello
> >
> >    I have migrated a working mailserver from Centos 4.7 to Centos 5.2.
> > The system uses postfix to receive messages from a mail relay and is
> > supposed to deliver them to  folders named after the users, following
> > the /home/firstname.lastname@domain template. Authentication is done via
> > mysql against a db running on another system.
> >    New accounts are created automatically when a mail has to be
> > delivered to an user which has never been seen before.
> >    For the users which existed before migration, everything is fine.
> > However, for non-existing (i.e. to be created) users the homedir is
> > created with wrong contexts, which prohibit postfix to finalize the
> > delivery. Once a message is received for a new user, the following is
> > created:
> >
> >    [root@imap2 ~]# ll -Zl /home/gigi.test\(a)nobugconsulting.ro/ -R
> > /home/gigi.test(a)nobugconsulting.ro/:                          total
> > 8                                                       drwx------ 2
> > root:object_r:home_root_t        postfix postfix 4096 Feb 17 01:05 tmp
> >
> > /home/gigi.test(a)nobugconsulting.ro/tmp:
> > total 4                               -rw------- 1
> > root:object_r:home_root_t        postfix postfix 0 Feb 17 01:05
> > 1234825528.P26797.imap2
> >
> >    After that postfix tries to do stuff on the newly created file and
> > selinux kicks in and denies access.
> >    Running restorecon at this point fixes things:
> >
> >    [root@imap2 ~]# restorecon -v -R
> > /home/gigi.test(a)nobugconsulting.ro                               
> > restorecon reset /home/gigi.test(a)nobugconsulting.ro context
> > root:object_r:home_root_t:s0->user_u:object_r:user_home_dir_t:s0
> > restorecon reset /home/gigi.test(a)nobugconsulting.ro/tmp context
> > root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0
> > restorecon reset
> > /home/gigi.test(a)nobugconsulting.ro/tmp/1234825528.P26797.imap2 context
> > root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0                    
> >
> >
> >
> >    I am running the following versions of packages:
> >
> > [root@imap2 ~]# rpm -qa kernel\* \*selinux\* postfix\*
> > kernel-xen-2.6.18-92.1.22.el5
> > libselinux-utils-1.33.4-5.1.el5
> > selinux-policy-targeted-2.4.6-203.el5
> > libselinux-1.33.4-5.1.el5
> > libselinux-python-1.33.4-5.1.el5
> > selinux-policy-2.4.6-203.el5
> > postfix-2.3.3-2.1.centos.mysql_pgsql
> >
> >    Selinux related packages have been upgraded last night in the hope to
> > fix the problem, postfix is almost stock centosplus 5.2, recompiled with
> > support for mysql but without postgresql- support.
> >
> >    Obviously I no not want to follow the result of  audit2allow,
> > home_root_t:dir should not be there in the first place:
> > [root@imap2 ~]# grep avc /var/log/audit/audit.log|audit2allow
> >
> > #============= postfix_virtual_t ==============
> > allow postfix_virtual_t home_root_t:dir { write remove_name create
> > add_name };
> > allow postfix_virtual_t home_root_t:file { write create unlink link
> > getattr };
> > allow postfix_virtual_t postfix_private_t:dir search;
> > allow postfix_virtual_t postfix_private_t:sock_file write;
> > allow postfix_virtual_t usr_t:file { read getattr };
> >
> >    Correct access rights and contexts seem to be:
> > [root@imap2 ~]# ls -l /home/ -dZ
> > drwxr-xr-x+ postfix postfix system_u:object_r:home_root_t    /home/
> > [root@imap2 ~]# ls -l /home/gigi.test\(a)nobugconsulting.ro/ -dZ
> > drwx------  postfix postfix user_u:object_r:user_home_dir_t 
> > /home/gigi.test(a)nobugconsulting.ro/
> >
> >    The only user on the system (beside root) is postfix:
> > [root@imap2 ~]# getent passwd postfix
> > postfix:x:89:89::/var/spool/postfix:/sbin/nologin
> >
> >    raw content of audit log after a failed delivery for a never-seen
> > before user:
> > type=AVC msg=audit(1234873447.682:45616): avc:  denied  { write } for 
> > pid=2958 comm="virtual"
> > path="/home/gigi.test(a)nobugconsulting.ro/tmp/1234873447.P2958.imap2"
> > dev=hda1 ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
> > tcontext=root:object_r:home_root_t:s0 tclass=file
> > type=SYSCALL msg=audit(1234873447.682:45616): arch=c000003e syscall=1
> > success=no exit=-13 a0=c a1=2b96176fe510 a2=1b5 a3=7228206f722e676e
> > items=0 ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89
> > egid=89 sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual"
> > exe="/usr/libexec/postfix/virtual"
> > subj=root:system_r:postfix_virtual_t:s0 key=(null)
> > type=AVC msg=audit(1234873447.710:45617): avc:  denied  { write } for 
> > pid=2958 comm="virtual" name="1234873447.P2958.imap2" dev=hda1
> > ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
> > tcontext=root:object_r:home_root_t:s0 tclass=file
> > type=SYSCALL msg=audit(1234873447.710:45617): arch=c000003e syscall=77
> > success=no exit=-13 a0=c a1=0 a2=2 a3=0 items=0 ppid=26787 pid=2958
> > auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89 sgid=0 fsgid=89
> > tty=(none) ses=7290 comm="virtual"
> exe="/usr/libexec/postfix/virtual"
> > subj=root:system_r:postfix_virtual_t:s0 key=(null)
> > type=AVC msg=audit(1234873447.710:45618): avc:  denied  { remove_name }
> > for  pid=2958 comm="virtual" name="1234873447.P2958.imap2"
> > dev=hda1ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
> > tcontext=root:object_r:home_root_t:s0 tclass=dir
> > type=SYSCALL msg=audit(1234873447.710:45618): arch=c000003e syscall=87
> > success=no exit=-13 a0=2b96176fdb80 a1=64 a2=4 a3=2b95fb0340ec items=0
> > ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89
> > sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual"
> > exe="/usr/libexec/postfix/virtual"
> > subj=root:system_r:postfix_virtual_t:s0 key=(null)
> >
> >
> >
> >
> >
> >
> >    My questions are
> > a) why does postfix create the initial home directories with a wrong
> > context ? Note this only happens for NEW users, messages for the users
> > which already existed [and have correct context] on the old system are
> > perfectly fine.
> >     
>  Does postfix actually create the homedir or was the homedir created by
>  an init script?  postfix does not know anything about SELinux but there
>  are rules about processes running as postfix_t creating files in
>  user_home_dir_t directories.  In your case it seems that the directory
>  was labeled home_root_t, which is where the problem is.
>
>     
/home exists;  everything below it is created (and should be created 
with correct contexts) by postfix in real time


> > b) what can I do to fix ?
> >
> >     
>  The restorecon should have fixed the homedir problem, 
I asssume you mean
restorecond ? It's running ...



>   the other policy I will add to the 5.4 update.
>
>  selinux-policy-2.4.6-213.el5  Should be up on
>  http://people.redhat.com/dwalsh/RHEL5/
>
>  Soon
>

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manuel Wolfshant wrote:
>  Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Manuel Wolfshant wrote:
> >  
> >> hello
> >>
> >>    I have migrated a working mailserver from Centos 4.7 to Centos 5.2.
> >> The system uses postfix to receive messages from a mail relay and is
> >> supposed to deliver them to  folders named after the users, following
> >> the /home/firstname.lastname@domain template. Authentication is done via
> >> mysql against a db running on another system.
> >>    New accounts are created automatically when a mail has to be
> >> delivered to an user which has never been seen before.
> >>    For the users which existed before migration, everything is fine.
> >> However, for non-existing (i.e. to be created) users the homedir is
> >> created with wrong contexts, which prohibit postfix to finalize the
> >> delivery. Once a message is received for a new user, the following is
> >> created:
> >>
> >>    [root@imap2 ~]# ll -Zl /home/gigi.test\(a)nobugconsulting.ro/ -R
> >> /home/gigi.test(a)nobugconsulting.ro/:                          total
> >> 8                                                       drwx------ 2
> >> root:object_r:home_root_t        postfix postfix 4096 Feb 17 01:05 tmp
> >>
> >> /home/gigi.test(a)nobugconsulting.ro/tmp:
> >> total 4                               -rw------- 1
> >> root:object_r:home_root_t        postfix postfix 0 Feb 17 01:05
> >> 1234825528.P26797.imap2
> >>
> >>    After that postfix tries to do stuff on the newly created file and
> >> selinux kicks in and denies access.
> >>    Running restorecon at this point fixes things:
> >>
> >>    [root@imap2 ~]# restorecon -v -R
> >> /home/gigi.test(a)nobugconsulting.ro                              
> >> restorecon reset /home/gigi.test(a)nobugconsulting.ro context
> >> root:object_r:home_root_t:s0->user_u:object_r:user_home_dir_t:s0
> >> restorecon reset /home/gigi.test(a)nobugconsulting.ro/tmp context
> >> root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0
> >> restorecon reset
> >> /home/gigi.test(a)nobugconsulting.ro/tmp/1234825528.P26797.imap2 context
> >> root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0                  
>
> >>
> >>
> >>
> >>    I am running the following versions of packages:
> >>
> >> [root@imap2 ~]# rpm -qa kernel\* \*selinux\* postfix\*
> >> kernel-xen-2.6.18-92.1.22.el5
> >> libselinux-utils-1.33.4-5.1.el5
> >> selinux-policy-targeted-2.4.6-203.el5
> >> libselinux-1.33.4-5.1.el5
> >> libselinux-python-1.33.4-5.1.el5
> >> selinux-policy-2.4.6-203.el5
> >> postfix-2.3.3-2.1.centos.mysql_pgsql
> >>
> >>    Selinux related packages have been upgraded last night in the hope to
> >> fix the problem, postfix is almost stock centosplus 5.2, recompiled with
> >> support for mysql but without postgresql- support.
> >>
> >>    Obviously I no not want to follow the result of  audit2allow,
> >> home_root_t:dir should not be there in the first place:
> >> [root@imap2 ~]# grep avc /var/log/audit/audit.log|audit2allow
> >>
> >> #============= postfix_virtual_t ==============
> >> allow postfix_virtual_t home_root_t:dir { write remove_name create
> >> add_name };
> >> allow postfix_virtual_t home_root_t:file { write create unlink link
> >> getattr };
> >> allow postfix_virtual_t postfix_private_t:dir search;
> >> allow postfix_virtual_t postfix_private_t:sock_file write;
> >> allow postfix_virtual_t usr_t:file { read getattr };
> >>
> >>    Correct access rights and contexts seem to be:
> >> [root@imap2 ~]# ls -l /home/ -dZ
> >> drwxr-xr-x+ postfix postfix system_u:object_r:home_root_t    /home/
> >> [root@imap2 ~]# ls -l /home/gigi.test\(a)nobugconsulting.ro/ -dZ
> >> drwx------  postfix postfix user_u:object_r:user_home_dir_t
> >> /home/gigi.test(a)nobugconsulting.ro/
> >>
> >>    The only user on the system (beside root) is postfix:
> >> [root@imap2 ~]# getent passwd postfix
> >> postfix:x:89:89::/var/spool/postfix:/sbin/nologin
> >>
> >>    raw content of audit log after a failed delivery for a never-seen
> >> before user:
> >> type=AVC msg=audit(1234873447.682:45616): avc:  denied  { write } for
> >> pid=2958 comm="virtual"
> >> path="/home/gigi.test(a)nobugconsulting.ro/tmp/1234873447.P2958.imap2"
> >> dev=hda1 ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
> >> tcontext=root:object_r:home_root_t:s0 tclass=file
> >> type=SYSCALL msg=audit(1234873447.682:45616): arch=c000003e syscall=1
> >> success=no exit=-13 a0=c a1=2b96176fe510 a2=1b5 a3=7228206f722e676e
> >> items=0 ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89
> >> egid=89 sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual"
> >> exe="/usr/libexec/postfix/virtual"
> >> subj=root:system_r:postfix_virtual_t:s0 key=(null)
> >> type=AVC msg=audit(1234873447.710:45617): avc:  denied  { write } for
> >> pid=2958 comm="virtual" name="1234873447.P2958.imap2"
> dev=hda1
> >> ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
> >> tcontext=root:object_r:home_root_t:s0 tclass=file
> >> type=SYSCALL msg=audit(1234873447.710:45617): arch=c000003e syscall=77
> >> success=no exit=-13 a0=c a1=0 a2=2 a3=0 items=0 ppid=26787 pid=2958
> >> auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89 sgid=0 fsgid=89
> >> tty=(none) ses=7290 comm="virtual"
> exe="/usr/libexec/postfix/virtual"
> >> subj=root:system_r:postfix_virtual_t:s0 key=(null)
> >> type=AVC msg=audit(1234873447.710:45618): avc:  denied  { remove_name }
> >> for  pid=2958 comm="virtual" name="1234873447.P2958.imap2"
> >> dev=hda1ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
> >> tcontext=root:object_r:home_root_t:s0 tclass=dir
> >> type=SYSCALL msg=audit(1234873447.710:45618): arch=c000003e syscall=87
> >> success=no exit=-13 a0=2b96176fdb80 a1=64 a2=4 a3=2b95fb0340ec items=0
> >> ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89
> >> sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual"
> >> exe="/usr/libexec/postfix/virtual"
> >> subj=root:system_r:postfix_virtual_t:s0 key=(null)
> >>
> >>
> >>
> >>
> >>
> >>
> >>    My questions are
> >> a) why does postfix create the initial home directories with a wrong
> >> context ? Note this only happens for NEW users, messages for the users
> >> which already existed [and have correct context] on the old system are
> >> perfectly fine.
> >>     
> > Does postfix actually create the homedir or was the homedir created by
> > an init script?  postfix does not know anything about SELinux but there
> > are rules about processes running as postfix_t creating files in
> > user_home_dir_t directories.  In your case it seems that the directory
> > was labeled home_root_t, which is where the problem is.
> >
> >   
>  
>  /home exists;  everything below it is created (and should be created
>  with correct contexts) by postfix in real time
>  
Why is postfix creating a homedir?   I have never seen this before.
That is where the problem is, selinux policy does not allow postfix to
create directories under /home (home_root_t), so it is being blocked.

>  
> >> b) what can I do to fix ?
> >>
> >>     
> > The restorecon should have fixed the homedir problem,
>  I asssume you mean restorecond ? It's running ...
>  
>   
Nope, restorecond does not watch homedirs being created.

>  
> >  the other policy I will add to the 5.4 update.
> >
> > selinux-policy-2.4.6-213.el5  Should be up on
> > http://people.redhat.com/dwalsh/RHEL5/
> >
> > Soon
> >   
>  
>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmaxTwACgkQrlYvE4MpobPefwCeJza1xSEv1TcKzaxijczpTDXz
> ZI8AoJyL76RFRYobtnh3riJ3JOWRFwLl
> =VaMl
> -----END PGP SIGNATURE-----

[Manuel Wolfshant]

Daniel J Walsh wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  Manuel Wolfshant wrote:
>    
> > Daniel J Walsh wrote:
> >     
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Manuel Wolfshant wrote:
> >>  
> >>       
> >>> hello
> >>>
> >>>    I have migrated a working mailserver from Centos 4.7 to Centos 5.2.
> >>> The system uses postfix to receive messages from a mail relay and is
> >>> supposed to deliver them to  folders named after the users, following
> >>> the /home/firstname.lastname@domain template. Authentication is done via
> >>> mysql against a db running on another system.
> >>>    New accounts are created automatically when a mail has to be
> >>> delivered to an user which has never been seen before.
> >>>    For the users which existed before migration, everything is fine.
> >>> However, for non-existing (i.e. to be created) users the homedir is
> >>> created with wrong contexts, which prohibit postfix to finalize the
> >>> delivery. Once a message is received for a new user, the following is
> >>> created:
> >>>
> >>>    [root@imap2 ~]# ll -Zl /home/gigi.test\(a)nobugconsulting.ro/ -R
> >>> /home/gigi.test(a)nobugconsulting.ro/:                          total
> >>> 8                                                       drwx------ 2
> >>> root:object_r:home_root_t        postfix postfix 4096 Feb 17 01:05 tmp
> >>>
> >>> /home/gigi.test(a)nobugconsulting.ro/tmp:
> >>> total 4                               -rw------- 1
> >>> root:object_r:home_root_t        postfix postfix 0 Feb 17 01:05
> >>> 1234825528.P26797.imap2
> >>>
> >>>    After that postfix tries to do stuff on the newly created file and
> >>> selinux kicks in and denies access.
> >>>    Running restorecon at this point fixes things:
> >>>
> >>>    [root@imap2 ~]# restorecon -v -R
> >>> /home/gigi.test(a)nobugconsulting.ro                              
> >>> restorecon reset /home/gigi.test(a)nobugconsulting.ro context
> >>> root:object_r:home_root_t:s0->user_u:object_r:user_home_dir_t:s0
> >>> restorecon reset /home/gigi.test(a)nobugconsulting.ro/tmp context
> >>> root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0
> >>> restorecon reset
> >>> /home/gigi.test(a)nobugconsulting.ro/tmp/1234825528.P26797.imap2 context
> >>> root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0              
>     
> >>>
> >>>
> >>>
> >>>    I am running the following versions of packages:
> >>>
> >>> [root@imap2 ~]# rpm -qa kernel\* \*selinux\* postfix\*
> >>> kernel-xen-2.6.18-92.1.22.el5
> >>> libselinux-utils-1.33.4-5.1.el5
> >>> selinux-policy-targeted-2.4.6-203.el5
> >>> libselinux-1.33.4-5.1.el5
> >>> libselinux-python-1.33.4-5.1.el5
> >>> selinux-policy-2.4.6-203.el5
> >>> postfix-2.3.3-2.1.centos.mysql_pgsql
> >>>
> >>>    Selinux related packages have been upgraded last night in the hope to
> >>> fix the problem, postfix is almost stock centosplus 5.2, recompiled with
> >>> support for mysql but without postgresql- support.
> >>>
> >>>    Obviously I no not want to follow the result of  audit2allow,
> >>> home_root_t:dir should not be there in the first place:
> >>> [root@imap2 ~]# grep avc /var/log/audit/audit.log|audit2allow
> >>>
> >>> #============= postfix_virtual_t ==============
> >>> allow postfix_virtual_t home_root_t:dir { write remove_name create
> >>> add_name };
> >>> allow postfix_virtual_t home_root_t:file { write create unlink link
> >>> getattr };
> >>> allow postfix_virtual_t postfix_private_t:dir search;
> >>> allow postfix_virtual_t postfix_private_t:sock_file write;
> >>> allow postfix_virtual_t usr_t:file { read getattr };
> >>>
> >>>    Correct access rights and contexts seem to be:
> >>> [root@imap2 ~]# ls -l /home/ -dZ
> >>> drwxr-xr-x+ postfix postfix system_u:object_r:home_root_t    /home/
> >>> [root@imap2 ~]# ls -l /home/gigi.test\(a)nobugconsulting.ro/ -dZ
> >>> drwx------  postfix postfix user_u:object_r:user_home_dir_t
> >>> /home/gigi.test(a)nobugconsulting.ro/
> >>>
> >>>    The only user on the system (beside root) is postfix:
> >>> [root@imap2 ~]# getent passwd postfix
> >>> postfix:x:89:89::/var/spool/postfix:/sbin/nologin
> >>>
> >>>    raw content of audit log after a failed delivery for a never-seen
> >>> before user:
> >>> type=AVC msg=audit(1234873447.682:45616): avc:  denied  { write } for
> >>> pid=2958 comm="virtual"
> >>>
> path="/home/gigi.test(a)nobugconsulting.ro/tmp/1234873447.P2958.imap2"
> >>> dev=hda1 ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
> >>> tcontext=root:object_r:home_root_t:s0 tclass=file
> >>> type=SYSCALL msg=audit(1234873447.682:45616): arch=c000003e syscall=1
> >>> success=no exit=-13 a0=c a1=2b96176fe510 a2=1b5 a3=7228206f722e676e
> >>> items=0 ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89
> >>> egid=89 sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual"
> >>> exe="/usr/libexec/postfix/virtual"
> >>> subj=root:system_r:postfix_virtual_t:s0 key=(null)
> >>> type=AVC msg=audit(1234873447.710:45617): avc:  denied  { write } for
> >>> pid=2958 comm="virtual" name="1234873447.P2958.imap2"
> dev=hda1
> >>> ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
> >>> tcontext=root:object_r:home_root_t:s0 tclass=file
> >>> type=SYSCALL msg=audit(1234873447.710:45617): arch=c000003e syscall=77
> >>> success=no exit=-13 a0=c a1=0 a2=2 a3=0 items=0 ppid=26787 pid=2958
> >>> auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89 sgid=0 fsgid=89
> >>> tty=(none) ses=7290 comm="virtual"
> exe="/usr/libexec/postfix/virtual"
> >>> subj=root:system_r:postfix_virtual_t:s0 key=(null)
> >>> type=AVC msg=audit(1234873447.710:45618): avc:  denied  { remove_name }
> >>> for  pid=2958 comm="virtual"
> name="1234873447.P2958.imap2"
> >>> dev=hda1ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
> >>> tcontext=root:object_r:home_root_t:s0 tclass=dir
> >>> type=SYSCALL msg=audit(1234873447.710:45618): arch=c000003e syscall=87
> >>> success=no exit=-13 a0=2b96176fdb80 a1=64 a2=4 a3=2b95fb0340ec items=0
> >>> ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89
> >>> sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual"
> >>> exe="/usr/libexec/postfix/virtual"
> >>> subj=root:system_r:postfix_virtual_t:s0 key=(null)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>    My questions are
> >>> a) why does postfix create the initial home directories with a wrong
> >>> context ? Note this only happens for NEW users, messages for the users
> >>> which already existed [and have correct context] on the old system are
> >>> perfectly fine.
> >>>     
> >>>         
> >> Does postfix actually create the homedir or was the homedir created by
> >> an init script?  postfix does not know anything about SELinux but there
> >> are rules about processes running as postfix_t creating files in
> >> user_home_dir_t directories.  In your case it seems that the directory
> >> was labeled home_root_t, which is where the problem is.
> >>
> >>   
> >>       
> > /home exists;  everything below it is created (and should be created
> > with correct contexts) by postfix in real time
> >
> >     
>  Why is postfix creating a homedir? 
Because that's where all the virtual users
have their mails.


>     I have never seen this before.
>  That is where the problem is, selinux policy does not allow postfix to
>  create directories under /home (home_root_t), so it is being blocked.
>
>     
I am sorry, I do not remember from which site was the setup taken. 4 
years or so since I installed it the first time in Centos 4.2, but if I 
am not mistaken it's an almost exact replica of the setup suggested by 
postfixadmin

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manuel Wolfshant wrote:
>  Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Manuel Wolfshant wrote:
> >  
> >> Daniel J Walsh wrote:
> >>    
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> Manuel Wolfshant wrote:
> >>>  
> >>>      
> >>>> hello
> >>>>
> >>>>    I have migrated a working mailserver from Centos 4.7 to Centos 5.2.
> >>>> The system uses postfix to receive messages from a mail relay and is
> >>>> supposed to deliver them to  folders named after the users, following
> >>>> the /home/firstname.lastname@domain template. Authentication is
> >>>> done via
> >>>> mysql against a db running on another system.
> >>>>    New accounts are created automatically when a mail has to be
> >>>> delivered to an user which has never been seen before.
> >>>>    For the users which existed before migration, everything is fine.
> >>>> However, for non-existing (i.e. to be created) users the homedir is
> >>>> created with wrong contexts, which prohibit postfix to finalize the
> >>>> delivery. Once a message is received for a new user, the following is
> >>>> created:
> >>>>
> >>>>    [root@imap2 ~]# ll -Zl /home/gigi.test\(a)nobugconsulting.ro/ -R
> >>>> /home/gigi.test(a)nobugconsulting.ro/:                          total
> >>>> 8                                                       drwx------ 2
> >>>> root:object_r:home_root_t        postfix postfix 4096 Feb 17 01:05 tmp
> >>>>
> >>>> /home/gigi.test(a)nobugconsulting.ro/tmp:
> >>>> total 4                               -rw------- 1
> >>>> root:object_r:home_root_t        postfix postfix 0 Feb 17 01:05
> >>>> 1234825528.P26797.imap2
> >>>>
> >>>>    After that postfix tries to do stuff on the newly created file and
> >>>> selinux kicks in and denies access.
> >>>>    Running restorecon at this point fixes things:
> >>>>
> >>>>    [root@imap2 ~]# restorecon -v -R
> >>>> /home/gigi.test(a)nobugconsulting.ro                             
> >>>> restorecon reset /home/gigi.test(a)nobugconsulting.ro context
> >>>> root:object_r:home_root_t:s0->user_u:object_r:user_home_dir_t:s0
> >>>> restorecon reset /home/gigi.test(a)nobugconsulting.ro/tmp context
> >>>> root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0
> >>>> restorecon reset
> >>>> /home/gigi.test(a)nobugconsulting.ro/tmp/1234825528.P26797.imap2 context
> >>>> root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0          
>        
> >>>>
> >>>>
> >>>>
> >>>>    I am running the following versions of packages:
> >>>>
> >>>> [root@imap2 ~]# rpm -qa kernel\* \*selinux\* postfix\*
> >>>> kernel-xen-2.6.18-92.1.22.el5
> >>>> libselinux-utils-1.33.4-5.1.el5
> >>>> selinux-policy-targeted-2.4.6-203.el5
> >>>> libselinux-1.33.4-5.1.el5
> >>>> libselinux-python-1.33.4-5.1.el5
> >>>> selinux-policy-2.4.6-203.el5
> >>>> postfix-2.3.3-2.1.centos.mysql_pgsql
> >>>>
> >>>>    Selinux related packages have been upgraded last night in the
> >>>> hope to
> >>>> fix the problem, postfix is almost stock centosplus 5.2, recompiled
> >>>> with
> >>>> support for mysql but without postgresql- support.
> >>>>
> >>>>    Obviously I no not want to follow the result of  audit2allow,
> >>>> home_root_t:dir should not be there in the first place:
> >>>> [root@imap2 ~]# grep avc /var/log/audit/audit.log|audit2allow
> >>>>
> >>>> #============= postfix_virtual_t ==============
> >>>> allow postfix_virtual_t home_root_t:dir { write remove_name create
> >>>> add_name };
> >>>> allow postfix_virtual_t home_root_t:file { write create unlink link
> >>>> getattr };
> >>>> allow postfix_virtual_t postfix_private_t:dir search;
> >>>> allow postfix_virtual_t postfix_private_t:sock_file write;
> >>>> allow postfix_virtual_t usr_t:file { read getattr };
> >>>>
> >>>>    Correct access rights and contexts seem to be:
> >>>> [root@imap2 ~]# ls -l /home/ -dZ
> >>>> drwxr-xr-x+ postfix postfix system_u:object_r:home_root_t    /home/
> >>>> [root@imap2 ~]# ls -l /home/gigi.test\(a)nobugconsulting.ro/ -dZ
> >>>> drwx------  postfix postfix user_u:object_r:user_home_dir_t
> >>>> /home/gigi.test(a)nobugconsulting.ro/
> >>>>
> >>>>    The only user on the system (beside root) is postfix:
> >>>> [root@imap2 ~]# getent passwd postfix
> >>>> postfix:x:89:89::/var/spool/postfix:/sbin/nologin
> >>>>
> >>>>    raw content of audit log after a failed delivery for a never-seen
> >>>> before user:
> >>>> type=AVC msg=audit(1234873447.682:45616): avc:  denied  { write } for
> >>>> pid=2958 comm="virtual"
> >>>>
> path="/home/gigi.test(a)nobugconsulting.ro/tmp/1234873447.P2958.imap2"
> >>>> dev=hda1 ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
> >>>> tcontext=root:object_r:home_root_t:s0 tclass=file
> >>>> type=SYSCALL msg=audit(1234873447.682:45616): arch=c000003e syscall=1
> >>>> success=no exit=-13 a0=c a1=2b96176fe510 a2=1b5 a3=7228206f722e676e
> >>>> items=0 ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89
> >>>> egid=89 sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual"
> >>>> exe="/usr/libexec/postfix/virtual"
> >>>> subj=root:system_r:postfix_virtual_t:s0 key=(null)
> >>>> type=AVC msg=audit(1234873447.710:45617): avc:  denied  { write } for
> >>>> pid=2958 comm="virtual" name="1234873447.P2958.imap2"
> dev=hda1
> >>>> ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
> >>>> tcontext=root:object_r:home_root_t:s0 tclass=file
> >>>> type=SYSCALL msg=audit(1234873447.710:45617): arch=c000003e syscall=77
> >>>> success=no exit=-13 a0=c a1=0 a2=2 a3=0 items=0 ppid=26787 pid=2958
> >>>> auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89 sgid=0 fsgid=89
> >>>> tty=(none) ses=7290 comm="virtual"
> exe="/usr/libexec/postfix/virtual"
> >>>> subj=root:system_r:postfix_virtual_t:s0 key=(null)
> >>>> type=AVC msg=audit(1234873447.710:45618): avc:  denied  {
> >>>> remove_name }
> >>>> for  pid=2958 comm="virtual"
> name="1234873447.P2958.imap2"
> >>>> dev=hda1ino=2736137 scontext=root:system_r:postfix_virtual_t:s0
> >>>> tcontext=root:object_r:home_root_t:s0 tclass=dir
> >>>> type=SYSCALL msg=audit(1234873447.710:45618): arch=c000003e syscall=87
> >>>> success=no exit=-13 a0=2b96176fdb80 a1=64 a2=4 a3=2b95fb0340ec items=0
> >>>> ppid=26787 pid=2958 auid=0 uid=0 gid=0 euid=89 suid=0 fsuid=89 egid=89
> >>>> sgid=0 fsgid=89 tty=(none) ses=7290 comm="virtual"
> >>>> exe="/usr/libexec/postfix/virtual"
> >>>> subj=root:system_r:postfix_virtual_t:s0 key=(null)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>    My questions are
> >>>> a) why does postfix create the initial home directories with a wrong
> >>>> context ? Note this only happens for NEW users, messages for the users
> >>>> which already existed [and have correct context] on the old system are
> >>>> perfectly fine.
> >>>>             
> >>> Does postfix actually create the homedir or was the homedir created by
> >>> an init script?  postfix does not know anything about SELinux but there
> >>> are rules about processes running as postfix_t creating files in
> >>> user_home_dir_t directories.  In your case it seems that the directory
> >>> was labeled home_root_t, which is where the problem is.
> >>>
> >>>         
> >> /home exists;  everything below it is created (and should be created
> >> with correct contexts) by postfix in real time
> >>
> >>     
> > Why is postfix creating a homedir?
>  Because that's where all the virtual users have their mails.
>  
>  
> >    I have never seen this before.
> > That is where the problem is, selinux policy does not allow postfix to
> > create directories under /home (home_root_t), so it is being blocked.
> >
> >   
>  I am sorry, I do not remember from which site was the setup taken. 4
>  years or so since I installed it the first time in Centos 4.2, but if I
>  am not mistaken it's an almost exact replica of the setup suggested by
>  postfixadmin
>  
>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
So postfix_virtual creates the homedir just to put a file in it and then
 send  it somewhere else?

If this is standard I can allow it, although it seems pretty strange.


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkma+x4ACgkQrlYvE4MpobOT0QCdHtHmVRx09D7guQE3PLUMdKbR
> AxwAn2xuHAhLG6/25dr413EKa6mxI63b
> =QRbF
> -----END PGP SIGNATURE-----

[Manuel Wolfshant]

On 02/17/2009 07:59 PM, Daniel J Walsh wrote:
>  Manuel Wolfshant wrote:
>    
> > Daniel J Walsh wrote:
> >     
> >> Manuel Wolfshant wrote:
> >>  
> >>       
> >>> Daniel J Walsh wrote:
> >>>    
> >>>         
> >>>> Manuel Wolfshant wrote:
> >>>>  
> >>>>      
> >>>>           
> >>>>> hello
> >>>>>
> >>>>>    I have migrated a working mailserver from Centos 4.7 to Centos
> 5.2.
> >>>>> The system uses postfix to receive messages from a mail relay and is
> >>>>> supposed to deliver them to  folders named after the users,
> following
> >>>>> the /home/firstname.lastname@domain template. Authentication is
> >>>>> done via
> >>>>> mysql against a db running on another system.
> >>>>>    New accounts are created automatically when a mail has to be
> >>>>> delivered to an user which has never been seen before.
> >>>>>    For the users which existed before migration, everything is fine.
> >>>>> However, for non-existing (i.e. to be created) users the homedir is
> >>>>> created with wrong contexts, which prohibit postfix to finalize the
> >>>>> delivery. Once a message is received for a new user, the following
> is
> >>>>> created:
> >>>>>
> >>>>>    [root@imap2 ~]# ll -Zl /home/gigi.test\(a)nobugconsulting.ro/ -R
> >>>>> /home/gigi.test(a)nobugconsulting.ro/:                          total
> >>>>> 8                                                       drwx------ 2
> >>>>> root:object_r:home_root_t        postfix postfix 4096 Feb 17 01:05
> tmp
> >>>>>
> >>>>> /home/gigi.test(a)nobugconsulting.ro/tmp:
> >>>>> total 4                               -rw------- 1
> >>>>> root:object_r:home_root_t        postfix postfix 0 Feb 17 01:05
> >>>>> 1234825528.P26797.imap2
> >>>>>
> >>>>>    After that postfix tries to do stuff on the newly created file
> and
> >>>>> selinux kicks in and denies access.
> >>>>>    Running restorecon at this point fixes things:
> >>>>>
> >>>>>    [root@imap2 ~]# restorecon -v -R
> >>>>> /home/gigi.test(a)nobugconsulting.ro                             
> >>>>> restorecon reset /home/gigi.test(a)nobugconsulting.ro context
> >>>>> root:object_r:home_root_t:s0->user_u:object_r:user_home_dir_t:s0
> >>>>> restorecon reset /home/gigi.test(a)nobugconsulting.ro/tmp context
> >>>>> root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0
> >>>>> restorecon reset
> >>>>> /home/gigi.test(a)nobugconsulting.ro/tmp/1234825528.P26797.imap2
> context
> >>>>> root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0      
>            
> >>>>>
> >>>>>
> >>>>>
> >>>>>    I am running the following versions of packages:
> >>>>>
> >>>>> [root@imap2 ~]# rpm -qa kernel\* \*selinux\* postfix\*
> >>>>> kernel-xen-2.6.18-92.1.22.el5
> >>>>> libselinux-utils-1.33.4-5.1.el5
> >>>>> selinux-policy-targeted-2.4.6-203.el5
> >>>>> libselinux-1.33.4-5.1.el5
> >>>>> libselinux-python-1.33.4-5.1.el5
> >>>>> selinux-policy-2.4.6-203.el5
> >>>>> postfix-2.3.3-2.1.centos.mysql_pgsql
> >>>>>
> >>>>>    Selinux related packages have been upgraded last night in the
> >>>>> hope to
> >>>>> fix the problem, postfix is almost stock centosplus 5.2, recompiled
> >>>>> with
> >>>>> support for mysql but without postgresql- support.
> >>>>>
> >>>>>    Obviously I no not want to follow the result of  audit2allow,
> >>>>> home_root_t:dir should not be there in the first place:
> >>>>> [root@imap2 ~]# grep avc /var/log/audit/audit.log|audit2allow
> >>>>>
> >>>>> #============= postfix_virtual_t ==============
> >>>>> allow postfix_virtual_t home_root_t:dir { write remove_name create
> >>>>> add_name };
> >>>>> allow postfix_virtual_t home_root_t:file { write create unlink link
> >>>>> getattr };
> >>>>> allow postfix_virtual_t postfix_private_t:dir search;
> >>>>> allow postfix_virtual_t postfix_private_t:sock_file write;
> >>>>> allow postfix_virtual_t usr_t:file { read getattr };
> >>>>>
> >>>>>    Correct access rights and contexts seem to be:
> >>>>> [root@imap2 ~]# ls -l /home/ -dZ
> >>>>> drwxr-xr-x+ postfix postfix system_u:object_r:home_root_t    /home/
> >>>>> [root@imap2 ~]# ls -l /home/gigi.test\(a)nobugconsulting.ro/ -dZ
> >>>>> drwx------  postfix postfix user_u:object_r:user_home_dir_t
> >>>>> /home/gigi.test(a)nobugconsulting.ro/
> >>>>>
> >>>>>    The only user on the system (beside root) is postfix:
> >>>>> [root@imap2 ~]# getent passwd postfix
> >>>>> postfix:x:89:89::/var/spool/postfix:/sbin/nologin
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>    My questions are
> >>>>> a) why does postfix create the initial home directories with a wrong
> >>>>> context ? Note this only happens for NEW users, messages for the
> users
> >>>>> which already existed [and have correct context] on the old system
> are
> >>>>> perfectly fine.
> >>>>>             
> >>>>>             
> >>>> Does postfix actually create the homedir or was the homedir created by
> >>>> an init script?  postfix does not know anything about SELinux but there
> >>>> are rules about processes running as postfix_t creating files in
> >>>> user_home_dir_t directories.  In your case it seems that the directory
> >>>> was labeled home_root_t, which is where the problem is.
> >>>>
> >>>>         
> >>>>           
> >>> /home exists;  everything below it is created (and should be created
> >>> with correct contexts) by postfix in real time
> >>>
> >>>     
> >>>         
> >> Why is postfix creating a homedir?
> >>       
> > Because that's where all the virtual users have their mails.
> >
> >
> >     
> >>    I have never seen this before.
> >> That is where the problem is, selinux policy does not allow postfix to
> >> create directories under /home (home_root_t), so it is being blocked.
> >>
> >>   
> >>       
> > I am sorry, I do not remember from which site was the setup taken. 4
> > years or so since I installed it the first time in Centos 4.2, but if I
> > am not mistaken it's an almost exact replica of the setup suggested by
> > postfixadmin
> >
> >     
>
>  So postfix_virtual creates the homedir just to put a file in it and then
>   send  it somewhere else?
>
>  If this is standard I can allow it, although it seems pretty strange.
>     
To be honest, I am not 100% sure how standard that is, although I am 
pretty sure that delivering to home dirs is not uncommon. Fact is that 
(in my case) postfix is the only user on the box and owns all the 
directories created below /home. Technically I presume that the whole 
structure could be moved anywhere else, but 4 years ago /home seemed a 
logical place, even if all users are virtual and defined in mysql.
Basically when doing a deliver, postfix uses maildirmake to create the 
top-level directory assigned to any specific user, leading to a tree 
like this:
    /home
    /home/specific.user
    /home/specific.user/cur  (cur stands for current)
    /home/specific.user/tmp
    /home/specific.user/new
The structure gets created when the very first message for a user is 
received.
As far as I have understood (it always "just worked" so I never did 
in-depth digging), messages are first created in /home/specific.user/tmp 
and after that copied to the final delivery place i.e. 
/home/specific.user/new. Once the user reads the message (via an imap / 
pop daemon), the message is transferred to /home/specific.user/cur (or 
to other folders, created via the IMAP daemon, but all of them placed 
below /home/specific.user)

[Paul Howarth]

Manuel Wolfshant wrote:
>  On 02/17/2009 07:59 PM, Daniel J Walsh wrote:
> > Manuel Wolfshant wrote:
> >  
> >> Daniel J Walsh wrote:
> >>    
> >>> Manuel Wolfshant wrote:
> >>>  
> >>>      
> >>>> Daniel J Walsh wrote:
> >>>>           
> >>>>> Manuel Wolfshant wrote:
> >>>>>  
> >>>>>               
> >>>>>> hello
> >>>>>>
> >>>>>>    I have migrated a working mailserver from Centos 4.7 to Centos
>
> >>>>>> 5.2.
> >>>>>> The system uses postfix to receive messages from a mail relay and
> is
> >>>>>> supposed to deliver them to  folders named after the users, 
> >>>>>> following
> >>>>>> the /home/firstname.lastname@domain template. Authentication is
> >>>>>> done via
> >>>>>> mysql against a db running on another system.
> >>>>>>    New accounts are created automatically when a mail has to be
> >>>>>> delivered to an user which has never been seen before.
> >>>>>>    For the users which existed before migration, everything is
> fine.
> >>>>>> However, for non-existing (i.e. to be created) users the homedir
> is
> >>>>>> created with wrong contexts, which prohibit postfix to finalize
> the
> >>>>>> delivery. Once a message is received for a new user, the 
> >>>>>> following is
> >>>>>> created:
> >>>>>>
> >>>>>>    [root@imap2 ~]# ll -Zl /home/gigi.test\(a)nobugconsulting.ro/
> -R
> >>>>>> /home/gigi.test(a)nobugconsulting.ro/:                         
> total
> >>>>>> 8                                                      
> drwx------ 2
> >>>>>> root:object_r:home_root_t        postfix postfix 4096 Feb 17 
> >>>>>> 01:05 tmp
> >>>>>>
> >>>>>> /home/gigi.test(a)nobugconsulting.ro/tmp:
> >>>>>> total 4                               -rw------- 1
> >>>>>> root:object_r:home_root_t        postfix postfix 0 Feb 17 01:05
> >>>>>> 1234825528.P26797.imap2
> >>>>>>
> >>>>>>    After that postfix tries to do stuff on the newly created file
>
> >>>>>> and
> >>>>>> selinux kicks in and denies access.
> >>>>>>    Running restorecon at this point fixes things:
> >>>>>>
> >>>>>>    [root@imap2 ~]# restorecon -v -R
> >>>>>> /home/gigi.test(a)nobugconsulting.ro                             
> >>>>>> restorecon reset /home/gigi.test(a)nobugconsulting.ro context
> >>>>>>
> root:object_r:home_root_t:s0->user_u:object_r:user_home_dir_t:s0
> >>>>>> restorecon reset /home/gigi.test(a)nobugconsulting.ro/tmp context
> >>>>>> root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0
> >>>>>> restorecon reset
> >>>>>> /home/gigi.test(a)nobugconsulting.ro/tmp/1234825528.P26797.imap2 
> >>>>>> context
> >>>>>> root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0  
>                
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>    I am running the following versions of packages:
> >>>>>>
> >>>>>> [root@imap2 ~]# rpm -qa kernel\* \*selinux\* postfix\*
> >>>>>> kernel-xen-2.6.18-92.1.22.el5
> >>>>>> libselinux-utils-1.33.4-5.1.el5
> >>>>>> selinux-policy-targeted-2.4.6-203.el5
> >>>>>> libselinux-1.33.4-5.1.el5
> >>>>>> libselinux-python-1.33.4-5.1.el5
> >>>>>> selinux-policy-2.4.6-203.el5
> >>>>>> postfix-2.3.3-2.1.centos.mysql_pgsql
> >>>>>>
> >>>>>>    Selinux related packages have been upgraded last night in the
> >>>>>> hope to
> >>>>>> fix the problem, postfix is almost stock centosplus 5.2,
> recompiled
> >>>>>> with
> >>>>>> support for mysql but without postgresql- support.
> >>>>>>
> >>>>>>    Obviously I no not want to follow the result of  audit2allow,
> >>>>>> home_root_t:dir should not be there in the first place:
> >>>>>> [root@imap2 ~]# grep avc /var/log/audit/audit.log|audit2allow
> >>>>>>
> >>>>>> #============= postfix_virtual_t ==============
> >>>>>> allow postfix_virtual_t home_root_t:dir { write remove_name
> create
> >>>>>> add_name };
> >>>>>> allow postfix_virtual_t home_root_t:file { write create unlink
> link
> >>>>>> getattr };
> >>>>>> allow postfix_virtual_t postfix_private_t:dir search;
> >>>>>> allow postfix_virtual_t postfix_private_t:sock_file write;
> >>>>>> allow postfix_virtual_t usr_t:file { read getattr };
> >>>>>>
> >>>>>>    Correct access rights and contexts seem to be:
> >>>>>> [root@imap2 ~]# ls -l /home/ -dZ
> >>>>>> drwxr-xr-x+ postfix postfix system_u:object_r:home_root_t   
> /home/
> >>>>>> [root@imap2 ~]# ls -l /home/gigi.test\(a)nobugconsulting.ro/ -dZ
> >>>>>> drwx------  postfix postfix user_u:object_r:user_home_dir_t
> >>>>>> /home/gigi.test(a)nobugconsulting.ro/
> >>>>>>
> >>>>>>    The only user on the system (beside root) is postfix:
> >>>>>> [root@imap2 ~]# getent passwd postfix
> >>>>>> postfix:x:89:89::/var/spool/postfix:/sbin/nologin
> >>>>>>
> >>>>>> [...]
> >>>>>>
> >>>>>>    My questions are
> >>>>>> a) why does postfix create the initial home directories with a
> wrong
> >>>>>> context ? Note this only happens for NEW users, messages for the
>
> >>>>>> users
> >>>>>> which already existed [and have correct context] on the old 
> >>>>>> system are
> >>>>>> perfectly fine.
> >>>>>>                         
> >>>>> Does postfix actually create the homedir or was the homedir 
> >>>>> created by
> >>>>> an init script?  postfix does not know anything about SELinux but 
> >>>>> there
> >>>>> are rules about processes running as postfix_t creating files in
> >>>>> user_home_dir_t directories.  In your case it seems that the 
> >>>>> directory
> >>>>> was labeled home_root_t, which is where the problem is.
> >>>>>
> >>>>>                   
> >>>> /home exists;  everything below it is created (and should be created
> >>>> with correct contexts) by postfix in real time
> >>>>
> >>>>             
> >>> Why is postfix creating a homedir?
> >>>       
> >> Because that's where all the virtual users have their mails.
> >>
> >>
> >>    
> >>>    I have never seen this before.
> >>> That is where the problem is, selinux policy does not allow postfix to
> >>> create directories under /home (home_root_t), so it is being blocked.
> >>>
> >>>         
> >> I am sorry, I do not remember from which site was the setup taken. 4
> >> years or so since I installed it the first time in Centos 4.2, but if I
> >> am not mistaken it's an almost exact replica of the setup suggested by
> >> postfixadmin
> >>
> >>     
> >
> > So postfix_virtual creates the homedir just to put a file in it and then
> >  send  it somewhere else?
> >
> > If this is standard I can allow it, although it seems pretty strange.
> >   
>  To be honest, I am not 100% sure how standard that is, although I am 
>  pretty sure that delivering to home dirs is not uncommon. Fact is that 
>  (in my case) postfix is the only user on the box and owns all the 
>  directories created below /home. Technically I presume that the whole 
>  structure could be moved anywhere else, but 4 years ago /home seemed a 
>  logical place, even if all users are virtual and defined in mysql.
>  Basically when doing a deliver, postfix uses maildirmake to create the 
>  top-level directory assigned to any specific user, leading to a tree 
>  like this:
>     /home
>     /home/specific.user
>     /home/specific.user/cur  (cur stands for current)
>     /home/specific.user/tmp
>     /home/specific.user/new
>  The structure gets created when the very first message for a user is 
>  received.
>  As far as I have understood (it always "just worked" so I never did 
>  in-depth digging), messages are first created in /home/specific.user/tmp 
>  and after that copied to the final delivery place i.e. 
>  /home/specific.user/new. Once the user reads the message (via an imap / 
>  pop daemon), the message is transferred to /home/specific.user/cur (or 
>  to other folders, created via the IMAP daemon, but all of them placed 
>  below /home/specific.user) 
This looks like standard delivery to maildir operation, with the 
addition of having the mailboxes in virtual user home directories under 
/home that are auto-created when necessary.

Given that there are no other users on the system, I wonder if 
everything would work smoothly if you made /home and everything 
underneath it mail_spool_t ?

Paul.

[Manuel Wolfshant]

Paul Howarth wrote:
>  This looks like standard delivery to maildir operation, with the 
>  addition of having the mailboxes in virtual user home directories 
>  under /home that are auto-created when necessary.
>
>  Given that there are no other users on the system, I wonder if 
>  everything would work smoothly if you made /home and everything 
>  underneath it mail_spool_t ?
>
>  Paul. 
And 99 points go to Paul for finding the correct answer. One more point 
if you tell me how to make the change permanent, so a full relabel won't 
bring it back to home_dir_t :)

[Paul Howarth]

Manuel Wolfshant wrote:
>  Paul Howarth wrote:
> >
> > This looks like standard delivery to maildir operation, with the 
> > addition of having the mailboxes in virtual user home directories 
> > under /home that are auto-created when necessary.
> >
> > Given that there are no other users on the system, I wonder if 
> > everything would work smoothly if you made /home and everything 
> > underneath it mail_spool_t ?
> >
> > Paul.
>  
>  And 99 points go to Paul for finding the correct answer. One more point 
>  if you tell me how to make the change permanent, so a full relabel won't 
>  bring it back to home_dir_t :) 
You could try:

# semanage fcontext -a -t mail_spool_t '/home(/.*)?'

but it's possible that genhomedircon would override that - I'm not sure. 
  Try it and see what happens if you do a restorecon somewhere under /home.

Paul.

[Manuel Wolfshant]

Paul Howarth wrote:
>  Manuel Wolfshant wrote:
> > Paul Howarth wrote:
> >>
> >> This looks like standard delivery to maildir operation, with the 
> >> addition of having the mailboxes in virtual user home directories 
> >> under /home that are auto-created when necessary.
> >>
> >> Given that there are no other users on the system, I wonder if 
> >> everything would work smoothly if you made /home and everything 
> >> underneath it mail_spool_t ?
> >>
> >> Paul.
> >
> > And 99 points go to Paul for finding the correct answer. One more 
> > point if you tell me how to make the change permanent, so a full 
> > relabel won't bring it back to home_dir_t :)
>
>  You could try:
>
>  # semanage fcontext -a -t mail_spool_t '/home(/.*)?'
>
>  but it's possible that genhomedircon would override that - I'm not 
>  sure.  Try it and see what happens if you do a restorecon somewhere 
>  under /home.
>
>  Paul. 
That was it. Thank you a lot