[SOLVED] Open /etc/postfix/main.cf: Permission denied

General support questions
altiris
Posts: 334
Joined: 2013/05/31 01:27:50

Re: Open /etc/postfix/main.cf: Permission denied

Post by altiris » 2014/08/06 01:02:16

TrevorH wrote:This is my output on a working el7 postfix

Code: Select all

[root@centos7 ~]# ls -laZ /etc/postfix/
drwxr-xr-x. root root system_u:object_r:postfix_etc_t:s0 .
drwxr-xr-x. root root system_u:object_r:etc_t:s0       ..
-rw-r--r--. root root system_u:object_r:postfix_etc_t:s0 access
-rw-r--r--. root root system_u:object_r:postfix_etc_t:s0 canonical
-rw-r--r--. root root system_u:object_r:postfix_etc_t:s0 generic
-rw-r--r--. root root system_u:object_r:postfix_etc_t:s0 header_checks
-rw-r--r--. root root system_u:object_r:postfix_etc_t:s0 main.cf
-rw-r--r--. root root system_u:object_r:postfix_etc_t:s0 master.cf
-rw-r--r--. root root system_u:object_r:postfix_etc_t:s0 relocated
-rw-r--r--. root root system_u:object_r:postfix_etc_t:s0 transport
-rw-r--r--. root root system_u:object_r:postfix_etc_t:s0 virtual
[root@centos7 ~]# ls -laZ `which postfix`
-rwxr-xr-x. root root system_u:object_r:postfix_master_exec_t:s0 /sbin/postfix
That is very strange. I have not touched/messed with SELinux so why is this happening? I used the CentOS Minimal installer so maybe theres a bug with it?
I just used the command

Code: Select all

chcon -v -u system_u -r object_r -t postfix_etc_t /etc/postfix
to make it so the permissions are exact like yours but I still have the same issue as OP. Very strange...

lklaus
Posts: 6
Joined: 2014/07/26 21:23:46

Re: Open /etc/postfix/main.cf: Permission denied

Post by lklaus » 2014/08/06 04:12:18

The minor difference on main.cf should not matter. I don't think SELinux is that strict on Centos7
Just after starting postfix, what does
ausearch -m avc -ts recent
Say? if empty, try a
semodulke -BD
And all of the above. Afterwards, do a
semodule -B
To restore don't audit rules

altiris
Posts: 334
Joined: 2013/05/31 01:27:50

Re: Open /etc/postfix/main.cf: Permission denied

Post by altiris » 2014/08/06 04:14:20

lklaus wrote:The minor difference on main.cf should not matter. I don't think SELinux is that strict on Centos7
Just after starting postfix, what does
ausearch -m avc -ts recent
Say? if empty, try a
semodulke -BD
And all of the above. Afterwards, do a
semodule -B
To restore don't audit rules
Thanks for posting a response, id like to inform you that I will only be able to give you an actual reply in the morning (12:13am here) and I need to get some rest, sorry. Thank you for helping though, I will reply later!!

EDIT: Here you go

Code: Select all

ausearch -m avc -ts recent
<no matches>
I ran "semodule -BD" and it made the system pause for a bit but then just returned back so I can enter another command (maybe notenough ram on vm?). The same goes for semodule -B

lklaus
Posts: 6
Joined: 2014/07/26 21:23:46

Re: Open /etc/postfix/main.cf: Permission denied

Post by lklaus » 2014/08/06 18:06:40

altiris wrote: EDIT: Here you go

Code: Select all

ausearch -m avc -ts recent
<no matches>
I ran "semodule -BD" and it made the system pause for a bit but then just returned back so I can enter another command (maybe notenough ram on vm?). The same goes for semodule -B
Ok, no "normal" denials.

For semodule, this is normal. It recompiles the policy, with -BD it disables "dontaudit" rules. This are rules that are expected to be violated often, with (normally) no bad effect (like trying to open /etc/shadow and then falling back to pam). So this takes some time. When this finishes, try to start postfix again and enter the ausearch command. To get the system back to normal (i.e. activate the dontaudit, otherwise your system will tend to be talkative...), the semodule -B recompiles policy for normal setup

Klaus

lklaus
Posts: 6
Joined: 2014/07/26 21:23:46

Re: Open /etc/postfix/main.cf: Permission denied

Post by lklaus » 2014/08/06 18:22:53

Another question comes to my mind... Do you run postfix chrooted? Is there a /etc/postfix/chroot-update?

altiris
Posts: 334
Joined: 2013/05/31 01:27:50

Re: Open /etc/postfix/main.cf: Permission denied

Post by altiris » 2014/08/06 19:56:49

lklaus wrote:
altiris wrote: EDIT: Here you go

Code: Select all

ausearch -m avc -ts recent
<no matches>
I ran "semodule -BD" and it made the system pause for a bit but then just returned back so I can enter another command (maybe notenough ram on vm?). The same goes for semodule -B
Ok, no "normal" denials.

For semodule, this is normal. It recompiles the policy, with -BD it disables "dontaudit" rules. This are rules that are expected to be violated often, with (normally) no bad effect (like trying to open /etc/shadow and then falling back to pam). So this takes some time. When this finishes, try to start postfix again and enter the ausearch command. To get the system back to normal (i.e. activate the dontaudit, otherwise your system will tend to be talkative...), the semodule -B recompiles policy for normal setup

Klaus
This is a bit confusing for me to comprehend but I am trying.

Code: Select all

[root@comp-data3 ~]# semodule -BD
[root@comp-data3 ~]# systemctl restart postfix
[root@comp-data3 ~]# ausearch -m avc -ts recent
----
time->Wed Aug  6 15:55:21 2014
type=SYSCALL msg=audit(1407354921.125:10148): arch=c000003e syscall=59 success=yes exit=0 a0=7fe64dfe3590 a1=7fe64dfe3990 a2=7fe64dfdec80 a3=ffffffff items=0 ppid=9186 pid=9188 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qmgr" exe="/usr/libexec/postfix/qmgr" subj=system_u:system_r:postfix_qmgr_t:s0 key=(null)
type=AVC msg=audit(1407354921.125:10148): avc:  denied  { noatsecure } for  pid=9188 comm="qmgr" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_qmgr_t:s0 tclass=process
type=AVC msg=audit(1407354921.125:10148): avc:  denied  { siginh } for  pid=9188 comm="qmgr" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_qmgr_t:s0 tclass=process
type=AVC msg=audit(1407354921.125:10148): avc:  denied  { rlimitinh } for  pid=9188 comm="qmgr" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_qmgr_t:s0 tclass=process
----
time->Wed Aug  6 15:55:21 2014
type=SYSCALL msg=audit(1407354921.125:10149): arch=c000003e syscall=59 success=yes exit=0 a0=7fe64dfe2ff0 a1=7fe64dfe3130 a2=7fe64dfdec80 a3=ffffffff items=0 ppid=9186 pid=9187 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pickup" exe="/usr/libexec/postfix/pickup" subj=system_u:system_r:postfix_pickup_t:s0 key=(null)
type=AVC msg=audit(1407354921.125:10149): avc:  denied  { noatsecure } for  pid=9187 comm="pickup" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_pickup_t:s0 tclass=process
type=AVC msg=audit(1407354921.125:10149): avc:  denied  { siginh } for  pid=9187 comm="pickup" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_pickup_t:s0 tclass=process
type=AVC msg=audit(1407354921.125:10149): avc:  denied  { rlimitinh } for  pid=9187 comm="pickup" scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:system_r:postfix_pickup_t:s0 tclass=process
----
time->Wed Aug  6 15:55:21 2014
type=SYSCALL msg=audit(1407354921.301:10150): arch=c000003e syscall=59 success=yes exit=0 a0=7f111560e460 a1=7f111560d780 a2=7f111560c010 a3=0 items=0 ppid=9189 pid=9190 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setroubleshootd" exe="/usr/bin/python2.7" subj=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1407354921.301:10150): avc:  denied  { noatsecure } for  pid=9190 comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1407354921.301:10150): avc:  denied  { siginh } for  pid=9190 comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1407354921.301:10150): avc:  denied  { rlimitinh } for  pid=9190 comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
----
time->Wed Aug  6 15:55:24 2014
type=SYSCALL msg=audit(1407354924.707:10151): arch=c000003e syscall=2 success=no exit=-13 a0=1aff9f0 a1=42 a2=1a4 a3=0 items=0 ppid=9189 pid=9190 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setroubleshootd" exe="/usr/bin/python2.7" subj=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1407354924.707:10151): avc:  denied  { write } for  pid=9190 comm="setroubleshootd" name=".dbenv.lock" dev="vda1" ino=18980220 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:rpm_var_lib_t:s0 tclass=file
(After this I ran the semodule -B command as you recommended). Seems like there isa lot more output here than before lol.
lklaus wrote:Another question comes to my mind... Do you run postfix chrooted? Is there a /etc/postfix/chroot-update?
Not that I know of, all i did was do "yum install postfix". There is no chroot-update file or folder.

cody
Posts: 9
Joined: 2014/05/07 17:42:16

Re: Open /etc/postfix/main.cf: Permission denied

Post by cody » 2014/08/06 21:57:46

If you don't know if it is running chroot then I would hope for your sake it is not (unless there actually is an individual package for it) because you run a script (or I guess you could do it manually but...). Specifically this:

/usr/share/doc/postfix-2.10.1/examples/chroot-setup/LINUX2
with CentOS 7...

Without looking too much at the previous messages much, it does seem suspicious because the way I read that error is EACCES (no, not a typo). The following C program will actually suggest it as such :

Code: Select all

#include <errno.h>
#include <string.h>
#include <stdio.h>

int main()
{
    printf("%s\n", strerror(EACCES));
    return 0;
}
Would show exactly : Permission denied.
(keep in mind that is only the error code message, not the full log message).

But indeed there can be multiple causes for the problem, SELinux being one of them (but I would find it odd that it does not work out of the box). I had a similar problem with both postfix and dovecot but in my case it was the fact CentOS 7 starts its uid/gid at a higher number than CentOS 6 and therefore when users were added to account - pardon the pun - for my setup, there was a mismatch. I know this is not exactly so helpful but I can only offer two other things to consider one is a next step suggestion (#2 in the list). It is how I did it in the end (see point 1 for what I mean and why I had two attempts at it).

1. You suggested you were up late. Let me tell you - from someone who knows sleep deprivation far too well - not enough sleep is a killer especially if you don't even know what you've done. I don't know what your schedule is like so maybe you were fine at that time but if not I would consider going back. Here's a good example: I made _really_ stupid mistakes when installing CentOS 7 the first time. The only reason I installed it is I had had a OOM (suspected) requiring a hard reset not long ago (in July I think but if not then June)... otherwise it was up for near 3 years. I am referring to neophyte mistakes. I actually was so frustrated that I went back and installed CentOS 6.5 and got that working in about an hour the next morning (I decided that after getting it installed I had enough and I needed to try to sleep). Two days later I tried again and did get it resolved. But there are some differences indeed from initscripts to systemd. And I indeed dislike some of it but with even a somewhat more clear head I managed OK. Mind you, last night was truly dreadful so hopefully all this is sound. But being tired is a very interesting thing in that you won't know how bad it is until later on (if it is in fact having an effect).

2. You have a CentOS 6.x postfix install working ? If yes, what I would suggest you go for next, is this :

- rsync your configuration (all files needed including those you created e.g., user files, ...) for postfix, to the VM (but not in to /etc/postfix itself). Then archive your postfix (in the VM) install (if you want to save it.. otherwise remove it).
- get your old config into /etc/postifx and add any users necessary relative to your config.
- of course, if there's specific changes in network (given that it is a VM it might very well be) then fix those first, for the VM.
- now, compare permissions and owners to the old setup and the 'copy thereof'. Make sure permissions (and use chmod if necessary) are the same and make sure that the uid/gid match (if not use chown as well, to the new user(s)).
- might want to also make sure database files are updated (timestamp and probably have ntp setup if you don't).

Then try to start it up. And if it still does not work, further inspect the log files. If you're so inclined you could go for what I did: use strace to see where exactly it is failing (but that's going to be only for programmers, so... ). The point of #2 is that you're using your old config but in a way that should work for the new setup. Because after all, the first worked, right? I can tell you that I used the exact same old config for the new environment and it worked fine after I fixed ownership/permission issues. So it isn't a change in the configuration and likely not a change in the software itself.

Aside that, I'm probably not much more of help here (because I tend to forget about forums and I'm not at all a good teacher and as I pointed out, I'm fortunate that I can think some of the time ...). So take this as it is but I know you can manage if you already have a working one (maybe you remember some services having drastically different configuration layouts, across major released. postfix isn't one of them here though).

altiris
Posts: 334
Joined: 2013/05/31 01:27:50

Re: Open /etc/postfix/main.cf: Permission denied

Post by altiris » 2014/08/07 01:20:47

cody wrote:If you don't know if it is running chroot then I would hope for your sake it is not (unless there actually is an individual package for it) because you run a script (or I guess you could do it manually but...). Specifically this:

/usr/share/doc/postfix-2.10.1/examples/chroot-setup/LINUX2
with CentOS 7...

Without looking too much at the previous messages much, it does seem suspicious because the way I read that error is EACCES (no, not a typo). The following C program will actually suggest it as such :

Code: Select all

#include <errno.h>
#include <string.h>
#include <stdio.h>

int main()
{
    printf("%s\n", strerror(EACCES));
    return 0;
}
Would show exactly : Permission denied.
(keep in mind that is only the error code message, not the full log message).

But indeed there can be multiple causes for the problem, SELinux being one of them (but I would find it odd that it does not work out of the box). I had a similar problem with both postfix and dovecot but in my case it was the fact CentOS 7 starts its uid/gid at a higher number than CentOS 6 and therefore when users were added to account - pardon the pun - for my setup, there was a mismatch. I know this is not exactly so helpful but I can only offer two other things to consider one is a next step suggestion (#2 in the list). It is how I did it in the end (see point 1 for what I mean and why I had two attempts at it).

1. You suggested you were up late. Let me tell you - from someone who knows sleep deprivation far too well - not enough sleep is a killer especially if you don't even know what you've done. I don't know what your schedule is like so maybe you were fine at that time but if not I would consider going back. Here's a good example: I made _really_ stupid mistakes when installing CentOS 7 the first time. The only reason I installed it is I had had a OOM (suspected) requiring a hard reset not long ago (in July I think but if not then June)... otherwise it was up for near 3 years. I am referring to neophyte mistakes. I actually was so frustrated that I went back and installed CentOS 6.5 and got that working in about an hour the next morning (I decided that after getting it installed I had enough and I needed to try to sleep). Two days later I tried again and did get it resolved. But there are some differences indeed from initscripts to systemd. And I indeed dislike some of it but with even a somewhat more clear head I managed OK. Mind you, last night was truly dreadful so hopefully all this is sound. But being tired is a very interesting thing in that you won't know how bad it is until later on (if it is in fact having an effect).

2. You have a CentOS 6.x postfix install working ? If yes, what I would suggest you go for next, is this :

- rsync your configuration (all files needed including those you created e.g., user files, ...) for postfix, to the VM (but not in to /etc/postfix itself). Then archive your postfix (in the VM) install (if you want to save it.. otherwise remove it).
- get your old config into /etc/postifx and add any users necessary relative to your config.
- of course, if there's specific changes in network (given that it is a VM it might very well be) then fix those first, for the VM.
- now, compare permissions and owners to the old setup and the 'copy thereof'. Make sure permissions (and use chmod if necessary) are the same and make sure that the uid/gid match (if not use chown as well, to the new user(s)).
- might want to also make sure database files are updated (timestamp and probably have ntp setup if you don't).

Then try to start it up. And if it still does not work, further inspect the log files. If you're so inclined you could go for what I did: use strace to see where exactly it is failing (but that's going to be only for programmers, so... ). The point of #2 is that you're using your old config but in a way that should work for the new setup. Because after all, the first worked, right? I can tell you that I used the exact same old config for the new environment and it worked fine after I fixed ownership/permission issues. So it isn't a change in the configuration and likely not a change in the software itself.

Aside that, I'm probably not much more of help here (because I tend to forget about forums and I'm not at all a good teacher and as I pointed out, I'm fortunate that I can think some of the time ...). So take this as it is but I know you can manage if you already have a working one (maybe you remember some services having drastically different configuration layouts, across major released. postfix isn't one of them here though).
This post was of very good help actually, I thank you for writing me this. I was in fact up late, the common procedure I have is I work with centos as a hobby late at night and encounter problems, etc. In the morning the next day I go and try to solve the problems (many which are careless mistake). I think I have made another one. In your procedure to copy the files/settings over, I realized you talked about "owners" and this is where it hit me. In one setting where it has mode = 0600 and user = I put postfix but the user I don't think I can recall making the user postfix (probably forgot). Should I just create the user in the terminal like I normally would? I'll Google around a bit but maybe this is the issue.

EDIT: Sadly I do not think this is the issue. Also, when I try doing "telnet localhost 143" I get a "connect to address 127.0.0.1: Connection refused". The port 143 is open on the firewall, I have tried it with firewalld stopped as well as selinux turned off and still same problem. So there seems to be something wrong with my config files set up. I will post them.

altiris
Posts: 334
Joined: 2013/05/31 01:27:50

Re: Open /etc/postfix/main.cf: Permission denied

Post by altiris » 2014/08/07 04:19:08

Code: Select all

grep -vE '^#|^;|^$' /etc/postfix/main.cf
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
myhostname = pc-data.datapc.com
mydomain = dataglobe.net
myorigin = $mydomain
inet_interfaces = all
inet_protocols = all
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
unknown_local_recipient_reject_code = 550
mynetworks = 192.168.12.0/24, 127.0.0.0/8
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
home_mailbox = Maildir/

debug_peer_level = 2
debugger_command =
	 PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
	 ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.10.1/samples
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_tls_security_level = may
smtpd_tls_key_file = /etc/pki/tls/private/mail.example.com.key
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.example.com.cert
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_tls_cache
tls_random_source = dev:/dev/urandom
smtpd_tls_auth_only = yes

Code: Select all

grep -vE '^#|^;|^$' /etc/dovecot/dovecot.conf
protocols = imap pop3 lmtp
listen = *, ::
dict {
  #quota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
  #expire = sqlite:/etc/dovecot/dovecot-dict-sql.conf.ext
}
!include conf.d/*.conf
!include_try local.conf
auth default {
mechanisms = plain login
passdb pam {
}
userdb passwd {
}
user = root
socket listen {
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
     }	
   }
}
ssl_cert_file = /etc/pki/tls/certs/mail.example.com.cert
ssl_key_file = /etc/pki/tls/private/mail.example.com.key
ssl_cipher_list = ALL:!LOW:!SSLv2

Code: Select all

grep -vE '^#|^;|^$' /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:~/Maildir 
mbox_write_locks = fcntl

Code: Select all

grep -vE '^#|^;|^$' /etc/dovecot/conf.d/10-auth.conf
disable_plaintext_auth = yes
auth_mechanisms = plain login
!include auth-system.conf.ext

Code: Select all

grep -vE '^#|^;|^$' /etc/dovecot/conf.d/10-master.conf
service imap-login {
  inet_listener imap {
    #port = 143
  }
  inet_listener imaps {
    #port = 993
    #ssl = yes
  }
  # Number of connections to handle before starting a new process. Typically
  # the only useful values are 0 (unlimited) or 1. 1 is more secure, but 0
  # is faster. <doc/wiki/LoginProcess.txt>
  #service_count = 1
  # Number of processes to always keep waiting for more connections.
  #process_min_avail = 0
  # If you set service_count=0, you probably need to grow this.
  #vsz_limit = $default_vsz_limit
}
service pop3-login {
  inet_listener pop3 {
    #port = 110
  }
  inet_listener pop3s {
    #port = 995
    #ssl = yes
  }
}
service lmtp {
  unix_listener lmtp {
    #mode = 0666
  }
  # Create inet listener only if you can't use the above UNIX socket
  #inet_listener lmtp {
    # Avoid making LMTP visible for the entire internet
    #address =
    #port = 
  #}
}
service imap {
  # Most of the memory goes to mmap()ing files. You may need to increase this
  # limit if you have huge mailboxes.
  #vsz_limit = $default_vsz_limit
  # Max. number of IMAP processes (connections)
  #process_limit = 1024
}
service pop3 {
  # Max. number of POP3 processes (connections)
  #process_limit = 1024
}
service auth {
  # auth_socket_path points to this userdb socket by default. It's typically
  # used by dovecot-lda, doveadm, possibly imap process, etc. Users that have
  # full permissions to this socket are able to get a list of all usernames and
  # get the results of everyone's userdb lookups.
  #
  # The default 0666 mode allows anyone to connect to the socket, but the
  # userdb lookups will succeed only if the userdb returns an "uid" field that
  # matches the caller process's UID. Also if caller's uid or gid matches the
  # socket's uid or gid the lookup succeeds. Anything else causes a failure.
  #
  # To give the caller full permissions to lookup all users, set the mode to
  # something else than 0666 and Dovecot lets the kernel enforce the
  # permissions (e.g. 0777 allows everyone full permissions).
  unix_listener auth-userdb {
    mode = 0666
    user = postfix 
    group = postfix
  }
  # Postfix smtp-auth
  #unix_listener /var/spool/postfix/private/auth {
  #  mode = 0666
  #}
  # Auth process is run as this user.
  #user = $default_internal_user
}
service auth-worker {
  # Auth worker process is run as root by default, so that it can access
  # /etc/shadow. If this isn't necessary, the user should be changed to
  # $default_internal_user.
  #user = root
}
service dict {
  # If dict proxy is used, mail processes should have access to its socket.
  # For example: mode=0660, group=vmail and global mail_access_groups=vmail
  unix_listener dict {
   # mode = 0600
   # user = postfix
   # group = postfix
  }
}
EDIT: If you look in the second box of text at the bottom, I never filled in the correct name for the .crt and .key I have corrected them now after I discovered the issue. Fail by me. I can now telnet localhost 143 correctly. So the issue comes back with the main.cf permissions/selinux.

cody
Posts: 9
Joined: 2014/05/07 17:42:16

Re: Open /etc/postfix/main.cf: Permission denied

Post by cody » 2014/08/07 13:53:51

I don't think dovecot is related per se, actually. The reason is this: I have in the past (and indeed when migrating to CentOS 7) set up one at a time. But user/group is one thing. The problem with that is if it is indeed /etc/postfix/main.cf then it should be readable. As for adding postfix user, I seem to think the postfix rpm post install scriptlet (I maintain my own repository, small as it may be, I have experience with the spec files) adds the user (typically that is the case). You can find out if there are any files without owners in the database. Given that it is a new environment I suspect this is not the case. What is entirely possible however, is that your postfix refers to a user/group that does not exist. You can find files/directories with a uid or gid that does not exist :

Code: Select all

# /usr/bin/find / \( -path '/proc*' -o -path '/dev*' -o -path '/sys*' -o -path '/backup*' \) -prune -o \( -nouser -o -nogroup \) -printf "%u %g (%M) %p\n"
Which will look like:

Code: Select all

501 apache (-rw-r--r--) /var/www
(you might also have other paths you want to prune from the list but those are the ones that come to mind. If you use bind-chroot then /var/named/chroot will appear as circular filesystem but find handles that gracefully).
if for example /var/www had no user but a proper group. And that above is something similar to my system (technically a directory under it, a specific vhost). This goes back to the user/group ids starting differently (I had apache as the group but the user was id 501 but now that user in question is id 1001. I forgot about this certain vhost because it is a test vhost, only resolvable via internal view in bind).

As for SELinux there is something you can do to determine if it is relevant. That is this:

you have it in a VM, right ? Just disable selinux (/etc/sysconfig/selinux) and reboot. Try to start postfix. If it starts then you can assume something is up with SELinux. If not, it isn't SELinux. Even if it was not a VM you'd probably be fine (and/or you could set it to permissive, but since you have it in a VM disabled is fine).

Code: Select all

# /usr/sbin/sed -i.orig 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux
Would change the line to disable selinux and save the original file in /etc/sysconfig/selinux.orig

There is one other thing that comes to mind although I don't think this is related as although Wietse Venema has suggested that there are (and this part is true) another copy of main.cf - specifically /usr/libexec/postfix/main.cf (check the entire directory) that could be used. But I've personally never had a problem here.

Although it was on the previous page I seem to remember that the /etc/postfix directory has proper permissions to actually open files in it. I cannot imagine /etc has an issue, either (and you run it as root so even when it drops privileges it would - or so I would think - read the configuration file first).

What does:

Code: Select all

# systemctl status postfix
# journalctl -xn
show ?

Also, I find that looking at /var/log/maillog and the surrounding lines is much more helpful (at times). This is a general rule, even. Why I think of this is it goes back to my programming experience (tracking down errors is beyond science; it is an art form). You can have one missing (or wrong) character on a line above and yet the compiler sees it (example: you don't end the line properly, above, so it is parsing it as one line but it sees it as the second line, in the file) and complains about the error on the line that appears fine. That example is not the only example. The point is that you can often get more insight into an issue with all the information available.

So I would do the following :
- check maillog and look around the failure (above and below it).
- if that doesn't give any information, try the two commands above to see if it gives any information.
- if that doesn't help, disable selinux and reboot (since in VM) to find out if it is or isn't selinux.
- if that does work, then you know where to go from. if it doesn't work you also know where not to go.
- if that still does not help, I would strongly consider what I suggested before: try to migrate your old install (that does work) in to the new one. configuration files for postfix from CentOS 6.x to CentOS 7.x shouldn't be an issue so it is not so much as the configuration as another problem.

I'm marking notify when a reply is posted so I can follow any further responses and maybe help (or try).

Post Reply