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

[altiris]

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,

Code: Select all

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).

Yes, I do not remember having to create the postfix user on centos 6 now that I think about it. When I run that command I get

Code: Select all

/usr/bin/find: File system loop detected; `/var/named/chroot/var/named' is part of the same file system loop as `/var/named'.
401 400 (-rw-r--r--) /usr/share/doc/amavisd-new-2.8.0/test-messages/sample-virus-executable.txt
401 400 (-rw-r--r--) /usr/share/doc/amavisd-new-2.8.0/test-messages/sample-42-mail-bomb.txt
401 400 (-rw-r--r--) /usr/share/doc/amavisd-new-2.8.0/test-messages/sample-spam-GTUBE-nojunk.txt
401 400 (-rw-r--r--) /usr/share/doc/amavisd-new-2.8.0/test-messages/sample-virus-simple.txt
401 400 (-rw-r--r--) /usr/share/doc/amavisd-new-2.8.0/test-messages/sample-spam-GTUBE-junk.txt
401 400 (-rw-r--r--) /usr/share/doc/amavisd-new-2.8.0/test-messages/sample-executable.txt
401 400 (-rw-r--r--) /usr/share/doc/amavisd-new-2.8.0/test-messages/sample-virus-nested.txt
401 400 (-rw-r--r--) /usr/share/doc/amavisd-new-2.8.0/test-messages/sample-nonspam.txt
401 400 (-rw-r--r--) /usr/share/doc/amavisd-new-2.8.0/test-messages/sample-spam.txt
401 400 (-rw-r--r--) /usr/share/doc/amavisd-new-2.8.0/test-messages/sample-badh.txt

However the thing about the /var/named/chroot shouldnt be too important, I tried installing bind-chroot but couldnt get it working (I have it working on centos 6 magically...) so I just removed it and am running it normally.

The thing about SELinux and postfix/dovecot well I know for a fact it is SELinux. What I am using as a "test" is the Roundcube installer, it does an SMTP (port 25 test) test as well as IMAP test (port 143). When SELinux is on (setenforce 1) I get "NOT OK" on roundcube installer for the SMTP test. When I disable SELinux (setenforce 0) I get "OK" back. Also, even with SELinux on/off Postfix will run, its just that I get the main.cf permission denied error when trying to do one of those tests.

There is another file, main.cf in /usr/libexec/postfix/ as well as a master.cf file.

Code: Select all

systemctl status postfix
postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled)
   Active: active (running) since Thu 2014-08-07 23:33:24 EDT; 51s ago
  Process: 7456 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
  Process: 7471 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
  Process: 7468 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
  Process: 7466 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
 Main PID: 7543 (master)
   CGroup: /system.slice/postfix.service
           ├─7543 /usr/libexec/postfix/master -w
           ├─7544 pickup -l -t unix -u
           └─7545 qmgr -l -t unix -u

Aug 07 23:33:23 necc-data3.dataglobe3.net systemd[1]: Starting Postfix Mail T...
Aug 07 23:33:24 necc-data3.dataglobe3.net postfix/master[7543]: daemon starte...
Aug 07 23:33:24 necc-data3.dataglobe3.net systemd[1]: Started Postfix Mail Tr...
Hint: Some lines were ellipsized, use -l to show in full.

Code: Select all

journalctl -xn
-- Logs begin at Wed 2014-08-06 23:47:33 EDT, end at Thu 2014-08-07 23:34:25 EDT
Aug 07 23:34:25 necc-data3.dataglobe3.net bacula-dir[7564]: bacula-dir: dird.c:1
Aug 07 23:34:25 necc-data3.dataglobe3.net bacula-dir[7564]: Possible causes: SQL
Aug 07 23:34:25 necc-data3.dataglobe3.net bacula-dir[7564]: 07-Aug 23:34 bacula-
Aug 07 23:34:25 necc-data3.dataglobe3.net bacula-dir[7564]: Please correct confi
Aug 07 23:34:25 necc-data3.dataglobe3.net systemd[1]: bacula-dir.service: main p
Aug 07 23:34:25 necc-data3.dataglobe3.net systemd[1]: Unit bacula-dir.service en
Aug 07 23:34:25 necc-data3.dataglobe3.net systemd[1]: bacula-dir.service holdoff
Aug 07 23:34:25 necc-data3.dataglobe3.net systemd[1]: Stopping Bacula-Director, 
-- Subject: Unit bacula-dir.service has begun shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit bacula-dir.service has begun shutting down.
Aug 07 23:34:25 necc-data3.dataglobe3.net systemd[1]: Starting Bacula-Director, 
-- Subject: Unit bacula-dir.service has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit bacula-dir.service has begun starting up.
Aug 07 23:34:25 necc-data3.dataglobe3.net systemd[1]: Started Bacula-Director, t
-- Subject: Unit bacula-dir.service has finished start-up
-- Defined-By: systemd

I really am just getting tired of this, I think maybe my install just errored with SELinux or something (maybe that rare occurrence of it happening idk). What I am going to do is as you suggest but I am going to create a nother virtual machine of centos 7. I dont know if I should waste my time and try a livecd again (I couldnt get netinstall working) but I guess I should use livecd again. I am going to copy the config files over from centos 6 but I wont copy or replace the files, instead I will just each file and copy the text and place it in. *sigh* Here we go again. EDIT: Ive done a netinstall in the virtual machine, I have selected "GNOME Desktop".

[cody]

Right. Note to self: use a text editor first like usual. I wrote a response but I got logged out. So I'm going to write a summary and not get the points I was hoping to get across.

If it works with SELinux enabled, then are you sure it is postfix that has the problem? Or is it the different copy of main.cf ? Alternatively, you can go here:
https://access.redhat.com/documentation ... -0068.html

and it shows how to disable SELinux for certain services.

Otherwise, consider this: don't feel bad if you disable SELinux. There is no black and white as a whole, for security. What IS bad is if you ignored all the layers or only relied on one thing (SELinux by itself, passwords by themselves, etc.). In other words, it is one tool of many and it - just like everything else - has problems too. Security is a many layered thing. And consider convenience (lack thereof) versus security. What happens? People resort to workarounds (e.g., writing passwords down). Is that better than password aging at a regular interval with certain restrictions and/or using passwords only once (which mind you, you should only use it once)? If you go to the point where you write it down, then no, it isn't better. This problem occurs with everything in security, mind you. I know some use ssh tunnels to avoid egress filtering (or get around it) while at work.

As for new install: maybe try minimal?

[TrevorH]

I'm pretty sure that one of the first steps done in this thread was setenforce 0 to put the system permissive and it made no difference so we've already eliminated selinux.

[cody]

I've seen permissive lead to problems still. But that's a moot point, at least from what I was getting at. At the same time, without seeing the logs in full, I cannot truthfully suggest I know that it is X, Y or Z. But that being noted, my suggested tests are not because I suspect something in particular (in some things I do but that's when I am the one working on the problem as in it is a problem I am having) but rather I am very good at debugging and troubleshooting. It is as I put earlier (I think I did): debugging is an art, not a science. An art you can always improve too, but it is much more than science. Basically though: you have to rule out everything not only by itself but in combinations. So it isn't that simple, I think (this is also why I suggested logs surrounding the error, permissions, owners/groups as well as the multiple copies of the files). It probably is not SELinux, true, but to ignore it is a potential problem. It might not be this occasion but it can be in another occasion. Maybe you weren't really responding to my point/thoughts or maybe you misunderstood, but either way, it is like this: you have to look at things from every angle and you cannot just because something seems to be fine does not mean it is fine (even if it is only some of the time, see below). This is sort of like ruling out medical problems to find what is truly going on (because not everything is treated by symptoms alone but rather finding the source of the symptoms).

Example: buffer overflows in programs with large memory spaces (therefore not writing/reading from outside of memory space and therefore not segfaulting when the problem is occuring)... or unitiatlised variables. They might seem to 'work' but just wait until the problem 'shows itself' (ironically you'll only know you have a problem rather than what the problem IS).

Then again, if the service is running with SELinux enabled, the real question is: is there a problem?

[altiris]

I'm pretty sure that one of the first steps done in this thread was setenforce 0 to put the system permissive and it made no difference so we've already eliminated selinux.

I believe I had done that since OP, the problem is MOST likely related to something with SELinux or with the extra main.cf file in /usr/libexec/postfix/main.cf

I've seen permissive lead to problems still. But that's a moot point, at least from what I was getting at. At the same time, without seeing the logs in full, I cannot truthfully suggest I know that it is X, Y or Z. But that being noted, my suggested tests are not because I suspect something in particular (in some things I do but that's when I am the one working on the problem as in it is a problem I am having) but rather I am very good at debugging and troubleshooting. It is as I put earlier (I think I did): debugging is an art, not a science. An art you can always improve too, but it is much more than science. Basically though: you have to rule out everything not only by itself but in combinations. So it isn't that simple, I think (this is also why I suggested logs surrounding the error, permissions, owners/groups as well as the multiple copies of the files). It probably is not SELinux, true, but to ignore it is a potential problem. It might not be this occasion but it can be in another occasion. Maybe you weren't really responding to my point/thoughts or maybe you misunderstood, but either way, it is like this: you have to look at things from every angle and you cannot just because something seems to be fine does not mean it is fine (even if it is only some of the time, see below). This is sort of like ruling out medical problems to find what is truly going on (because not everything is treated by symptoms alone but rather finding the source of the symptoms).

Example: buffer overflows in programs with large memory spaces (therefore not writing/reading from outside of memory space and therefore not segfaulting when the problem is occuring)... or unitiatlised variables. They might seem to 'work' but just wait until the problem 'shows itself' (ironically you'll only know you have a problem rather than what the problem IS).

Then again, if the service is running with SELinux enabled, the real question is: is there a problem?

I think we are misunderstanding each other. You say " It probably is not SELinux, true,..." however I believe that it IS SELinux that is causing the problem because when I disable SELinux, I can send out mail on port 25 (or rather successfully do the roundcube smtp mail test). Now you ask me, is there a problem with postfix running with SELinux enabled and that answer is yes. Its yes because I get an error about the /etc/postfix/main.cf file permissions being denied and being unable to send out email through smtp on the roundcube installer. However, if I disable SELinux I CAN send out email through the smtp port on the roundcube installer. Also, this is another varible but whether or not SELinux is enabled/disabled I can log in through IMAP (which uses the service Dovecot) so again, in a way I believe this would further confirm the issue is with SELinux and postfix permissions. If you really want a log I can paste one but as I said I have a new CO7 VM (I stil have the original one also) that was a netinstall to see if I get the same problem.

[cody]

Then again, if the service is running with SELinux enabled, the real question is: is there a problem?

I think we are misunderstanding each other. You say " It probably is not SELinux, true,..." however I believe that it IS SELinux that is causing the problem because when I disable SELinux, I can send out mail on port 25 (or rather successfully do the roundcube smtp mail test). Now you ask me, is there a problem with postfix running with SELinux enabled and that answer is yes. Its yes because I get an error about the /etc/postfix/main.cf file permissions being denied and being unable to send out email through smtp on the roundcube installer. However, if I disable SELinux I CAN send out email through the smtp port on the roundcube installer. Also, this is another varible but whether or not SELinux is enabled/disabled I can log in through IMAP (which uses the service Dovecot) so again, in a way I believe this would further confirm the issue is with SELinux and postfix permissions. If you really want a log I can paste one but as I said I have a new CO7 VM (I stil have the original one also) that was a netinstall to see if I get the same problem.

Yes, you're right then: I did misunderstand. The reason I suggested trying disabling SELinux is exactly to rule out other issues or SELinux itself. And it also shows what I mean with permissive mode not always being perfect (nothing is; everything has pros and cons and cons and pros (similar is good and evil. evil comes with good and vice versa)). Since the service was started, I figured it was a DIFFERENT test (that you referred to or if not I at least THOUGHT you referred to) that was failing and not postfix itself. Apologies. In that case, my previous thoughts do apply. Those include the link that refers to how to disable SELinux for a service as well as the fact that security is a many layered thing and so SELinux is one layer of many. Just because you have SELinux enabled does not mean you have your firewall wide open, or you allow icmp redirects, or you allow password-less logins, list goes on and on. The problem is: security is not a black and white concept and each environment will have different variables. For instance, I don't need sudo on one of my servers because it is sitting right next to me, I'm the only one who logs in (and have multiple passwords, require - for remote - ssh keys with passphrases, no password-less logins, actually - edit here - no passwords for remote login at all: key required... the no password-less refers to logins on the system itself), I require wheel group and if I wanted to I could require console log on only. On the other hand, one of my servers does need sudo and it specifies the exact commands and options and the options arguments that can be run as sudo. It really isn't so simple - nothing is... there's always many variables - and I think sometimes this is forgotten. One of the things I wrote initially but it got lost (when I was logged out) is that if you happen to have restrictions so tight that users go for work arounds, then what are you gaining security wise? Not much. And what are you gaining related to the users? You're frustrating them enough to do things like writing passwords down or using the same password on different networks, both of which are bad bad bad. But they're still done.

So with that, I think the real question is which main.cf is it failing. As for SELinux, well... again, different environments have different requirements. The problem is relying on one or two things, and the problem is NOT disabling one of many layers. If you want to go so far you could add a bastion host, ingress and egress filtering both at the MAC and IP level, keys, ... To suggest one thing is the one critical thing is flawed because there is no SINGLE critical thing. That's a fact. In general, relying on something to take care of the problem so much is a problem itself and WILL in the end bite you and it will be a vicious bite indeed (even if that is because you are thinking less so unable to resolve problems both in general or even about what you relied on so much).

As for logs: I don't need the full log and it might not even be necessary at all. The point is that one line is often not enough. I gave an example - albeit programming errors - earlier in this thread but this applies to errors of this kind too.

[altiris]

Well, I copied my centos 6 postfix and dovecot configurations/settings onto the new net install virtual machine (I didn't replace any files, I used nano to go into each file and copied/replaced the text) but I am getting some error with certificates so it seems like I was either careless or my configurations from centos 6 aren't working for some reason with 7. I will be unavailable for a while so I won't be able to test anything further.

[cody]

Mine works fine, for whatever it is worth. And whether or not you being unavailable is for a break or not, I can only suggest that the break that is a consequence of being gone, is probably a good thing.

[altiris]

Mine works fine, for whatever it is worth. And whether or not you being unavailable is for a break or not, I can only suggest that the break that is a consequence of being gone, is probably a good thing.

I think I just screwed up something with the certificates as I was getting something about /etc/pki (can't remember the rest) not being found or something in the mail log. I was rushing a bit to do this before I had to get off the computer so maybe that's why. If I still can't get it I'll try copying the files from the first centos vm or do everything manually again.

[altiris]

Well after I setting everything up again, I got the same main.cf permissions denied error. However, something I may have not noticed or dismissed before was that a notification would appear on the bottom of my screen about "AVC Denial" whenever I would try doing the SMTP test. I clicked view and "details" and it says about how postfix is trying to do something (can't remember what it said and I cant get it to appear any more) and to use the command

Code: Select all

setsebool -P httpd_can_sendmail=1 

to let it do so. This seems similar to the command setsebool -P httpd_can_network_connect=1