oddity with postfix delivering to homedir
Manuel Wolfshant
wolfy at nobugconsulting.ro
Tue Feb 17 14:32:53 UTC 2009
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 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.
>>>
>>>
>>>
>> /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
More information about the fedora-selinux-list
mailing list