oddity with postfix delivering to homedir

Daniel J Walsh dwalsh at redhat.com
Tue Feb 17 13:32:44 UTC 2009


-----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 at 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 at imap2 ~]# ll -Zl /home/gigi.test\@nobugconsulting.ro/ -R
> /home/gigi.test at nobugconsulting.ro/:                          total
> 8                                                       drwx------ 2
> root:object_r:home_root_t        postfix postfix 4096 Feb 17 01:05 tmp
> 
> /home/gigi.test at 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 at imap2 ~]# restorecon -v -R
> /home/gigi.test at nobugconsulting.ro                               
> restorecon reset /home/gigi.test at nobugconsulting.ro context
> root:object_r:home_root_t:s0->user_u:object_r:user_home_dir_t:s0
> restorecon reset /home/gigi.test at nobugconsulting.ro/tmp context
> root:object_r:home_root_t:s0->user_u:object_r:user_home_t:s0
> restorecon reset
> /home/gigi.test at 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 at 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 at 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 at imap2 ~]# ls -l /home/ -dZ
> drwxr-xr-x+ postfix postfix system_u:object_r:home_root_t    /home/
> [root at imap2 ~]# ls -l /home/gigi.test\@nobugconsulting.ro/ -dZ
> drwx------  postfix postfix user_u:object_r:user_home_dir_t 
> /home/gigi.test at nobugconsulting.ro/
> 
>    The only user on the system (beside root) is postfix:
> [root at 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 at 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 at 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-----




More information about the fedora-selinux-list mailing list