Systemctl httpd.service lacks root-permission

Rocky Linux Tech Help
1

It happen when configuring postfix and dovecot on a new installation where httpd ran fine.
I have no clue what i fubar’ed.

httpd won’t start anymore useing systemctl:
(13)Permission denied: AH00072: make_sock: could not bind to address [::]:80
Same goes for postfix.service:
postfix/master[1093]: fatal: bind ######:10::aaf port 25: Permission denied
and
dovecot[1277]: Error: service(imap-login): listen(#######:10::aaf, 993) failed:

When I start them as root from a terminal they run OK:

netstat -plnt (partly)

tcp6 :993 :::* LISTEN 3626/dovecot
tcp6 :443 :::* LISTEN 3445/httpd

Any ideas?

TIA
Jaap

2

Can you show the exact commands that fail, and then the exact commands that work, and clarify where you see the errors.

3

The failure happens with:

  • systemctl start postfix.service
  • systemctl start dovecot.service
  • systemctl start httpd.service

All tree start correctly if started from shell:

  • httpd
  • dovecot
  • postfix start

Errors are in logfiles

  • /var/log/httpd/error_log
  • /var/log/dovecot.log
  • /var/log/maillog

I hope this clarifies the problem.

TIA
Jaap

4

Feel free to share the contents of your error logs. You can also temporarily increase the verbosity of the logs by altering the systemd units. Add -e debug to the httpd ExecStart= and -v to postfix.

5

So as far as I know, it’s normal for this command to require root (or sudo).

You can set up --user services with systemd, but I don’t think the official Rocky httpd allows that.

6

Logs (for dovecot) as presented by cockpit (new → old ) after reboot

Service logs
November 9, 2024
7:53 AM Failed to start Dovecot IMAP/POP3 email server. systemd
7:53 AM dovecot.service: Failed with result ‘exit-code’. systemd
7:53 AM dovecot.service: Main process exited, code=exited, status=89/n/a systemd
7:53 AM Fatal: Failed to start listeners dovecot
7:53 AM Error: service(imap-login): listen(#:#:5ab:10::aaf, 993) failed: Permission denied dovecot
7:53 AM Error: bind(#:#:5ab:10::aaf, 993) failed: Permission denied dovecot
7:53 AM Error: service(pop3-login): listen(#:#:5ab:10::aaf, 995) failed: Permission denied dovecot
7:53 AM Error: bind(#:#:5ab:10::aaf, 995) failed: Permission denied dovecot
7:53 AM Starting Dovecot IMAP/POP3 email server… systemd

This is run as root (same when I did by hand)

You mention flag –user, where would this be (so I can remove it :slightly_smiling_face:)

TIA
Jaap

7

The logs don’t say much, so again, maybe try increasing the log verbosity.
Right now we can only guess, so let’s try to rule out selinux. Please set it temporarily to permissive mode and check if you can start the services. After that don’t forget to turn it back on.

[jp@rocky ~]$ sudo setenforce 0
[jp@rocky ~]$ getenforce
Permissive
1 Like
8

THANKS,

It seems to be selinux; I probably forgot to restorecon.
I will check.

Thanks again

Jaap

9

Following the debug suggestion of hs303 I determined that selinux refused permission on the ports. So I ran a full restorecon, an omission that I ran into before.
This does not solve the problem. I than investigated the selinix system modifications performed ‘on the suggestion of’ the SELinux access control errors reported bij cockpit. All involved ports are modified conform these suggestions:

  • port -a -t ssh_port_t -r ‘s0’ -p tcp 25
  • port -a -t ssh_port_t -r ‘s0’ -p tcp 80
  • port -a -t ssh_port_t -r ‘s0’ -p tcp 443
  • port -a -t ssh_port_t -r ‘s0’ -p tcp 465
  • port -a -t ssh_port_t -r ‘s0’ -p tcp 587
  • port -a -t ssh_port_t -r ‘s0’ -p tcp 993
  • port -a -t ssh_port_t -r ‘s0’ -p tcp 995

There are no selinux -errors reported. How do i find out what’s bothering selinux ?

TIA
Jaap

10

Install this package:

dnf install policycoreutils-python-utils

and then do:

audit2why -a

it should report stuff back explaining why there are problems. You can also use:

audit2allow -a

which will then say what you can do to fix issues, be it using setsebool or generating selinux modules to fix the issue.

If you want further help with the above commands, please ensure to post the output after running the commands so we can see what is exactly going on.

11

THANKS
for all the help

Analysis showed that the extra flag ssh_port_t put on the ports made them ssh ports. Removing this flag:
semanage port -d -t ssh_port_t -p tcp [port#] fixed it.

Only port 25 is still refused. Will keep looking where/how that happens.
Learned a lot from all replies; thanks again.

Jaap

1 Like