MTA unable to start due to wrong /dev/null permissions: Difference between revisions

No edit summary
 
(21 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{BC|Community Sandbox}}
__FORCETOC__
<div class="col-md-12 ibox-content">
=MTA unable to start due to wrong /dev/null permissions=
=MTA unable to start due to wrong /dev/null permissions=
{{KB|{{ZC}}|{{ZCS 8.6}}|{{ZCS 8.5}}|{{ZCS 8.0}}|}}
{{KB|{{ZC}}|{{ZCS 8.6}}|{{ZCS 8.5}}|{{ZCS 8.0}}|}}


=Problem=
MTA unable to start due to wrong /dev/null permissions. There are two symptoms that may indicate that:


<!-- Wiki/Article Body -->
* 1. Switching to a zimbra user results in the following output:
 
===Problem===
 
There are two symptoms that may indicate that:
 
1. Switch to a zimbra user results in the following output:
 
  -bash: /dev/null: Permission denied
  -bash: /dev/null: Permission denied
  -bash: /dev/null: Permission denied
  -bash: /dev/null: Permission denied
Line 37: Line 34:
  failed.
  failed.


2. The second symptom is that MTA will not start.  
* 2. The second symptom is that MTA will not start.  
---
===Cause===


The problem might be caused by different things. One could be that the permissions are changed during boot time by a security software. Another cause might be that udev is missing a rule, or the rule granting rights to the /dev/null file is changed due to an upgrade of udev to systed-tools.  
=Cause=
---
The problem might be caused by different things. One could be that the permissions are changed during boot time by a security software. Another cause might be that udev is missing a rule, or the rule granting rights to the /dev/null file are changed due to an upgrade of udev to systemd-tools.  
===Troubleshooting===


1. We can check in /lib/udev/rules.d the 50-udev-default.rules file (CentOS release 6.7), and make sure there is a line like that:
=Resolution=
To fix the permissions, we can do the following:
 
* 1) As root, delete the currently existing /dev/null:
# rm /dev/null</code>
 
* 2) Recreate it with the '''mknod''' command:
# mknod -m 0666 /dev/null c 1 3
 
=Troubleshooting=
'''1.''' '''W'''e can check in /lib/udev/rules.d the 50-udev-default.rules file (CentOS release 6.7), and make sure there is a line like the following or similar if its a different distribution:
  KERNEL=="null|zero|full|random|urandom", MODE="0666"
  KERNEL=="null|zero|full|random|urandom", MODE="0666"


2. Can create persistent audit watch rule, in order to determine whether anything is changing /dev/null permissions after boot.
'''2.''' '''I'''f that line is there, but the rights are still wrong, we can create persistent audit watch rule, in order to determine whether anything is changing /dev/null permissions after boot.


a) Set up a persistent audit watch in /etc/audit/audit.rules which will capture any write or attribute changes that are made to /dev/null. Include a '''key''' such as '''null-watch''' in order to easily search later for audit messages related to this rule. Please note, this rule needs to be included at some point after the '''-D''' rule at the top of that file which removes rules initially before proceeding systematically through the file.  
* a) Set up a persistent audit watch in '''/etc/audit/audit.rules''' which will capture any write or attribute changes that are made to /dev/null. Include a '''key''' such as '''null-watch''' in order to easily search later for audit messages related to this rule. Please note, this rule needs to be included at some point after the '''-D''' rule at the top of that file which removes rules initially before proceeding systematically through the file.  
Ideally after the line: "# Feel free to add below this line. See auditctl man page".
Ideally our rule should be after the line: ''# Feel free to add below this line. See auditctl man page''.


add the following line:
add the following line:
  -w /dev/null -p wa -k null-watch
  -w /dev/null -p wa -k null-watch


b) Once this is in place, restart the auditd service in order to query the rules file and initiate this watch:
'''w''' - write to the file
'''a''' - change in the file’s attribute       
 
* b) Once this is in place, restart the auditd service in order to query the rules file and initiate this watch:
  service auditd restart
  service auditd restart


c) Check that the rule is in place:
* c) Check that the rule is in place:
  # auditctl -l
  # auditctl -l
  LIST_RULES: exit,always watch=/dev/null perm=wa key=null-watch
  LIST_RULES: exit,always watch=/dev/null perm=wa key=null-watch


d) Then check that auditing is enabled:
* d) Then check that auditing is enabled:
  # auditctl -s
  # auditctl -s
  AUDIT_STATUS: enabled=1 flag=1 pid=1826 rate_limit=0 backlog_limit=320 lost=0 backlog=0
  AUDIT_STATUS: enabled=1 flag=1 pid=1826 rate_limit=0 backlog_limit=320 lost=0 backlog=0


e) If not, enable auditing and ensure that the auditd service is configured to run persistently, in the appropriate run level:
* e) If not, enable auditing and ensure that the auditd service is configured to run persistently, in the appropriate run level:
  auditctl -e 1
  auditctl -e 1
  chkconfig --list auditd
  chkconfig --list auditd


f) Reboot the system
* f) Reboot the system


g) After the reboot, if the /dev/null has wrong permissions, check for any audit messages related to the watch using the following command:
* g) After the reboot, if the /dev/null has wrong permissions, check for any audit messages related to the watch using the following command:
  ls -al /dev/null  
  ls -al /dev/null  
  ausearch -i -k null-watch
  ausearch -i -k null-watch
---
===Resolution===
To fix the permissions, we can do the following:
1) As root, delete the currently existing /dev/null:
# rm /dev/null</code>


2) Recreate it with the '''mknod''' command:
----
# mknod -m 0666 /dev/null c 1 3
{{Article Footer|Zimbra Collaboration 8.6, 8.5|04/22/2016}}
{{NeedSME|Teodor|SME2|Copy Editor}}

Latest revision as of 16:20, 26 April 2016

MTA unable to start due to wrong /dev/null permissions

   KB 22604        Last updated on 2016-04-26  




0.00
(0 votes)

Problem

MTA unable to start due to wrong /dev/null permissions. There are two symptoms that may indicate that:

  • 1. Switching to a zimbra user results in the following output:
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
/opt/zimbra/libexec/get_plat_tag.sh: line 138: /dev/null: Permission denied
/opt/zimbra/libexec/get_plat_tag.sh: line 143: /dev/null: Permission denied
/opt/zimbra/libexec/get_plat_tag.sh: line 148: /dev/null: Permission denied
/opt/zimbra/libexec/get_plat_tag.sh: line 153: /dev/null: Permission denied
/opt/zimbra/libexec/get_plat_tag.sh: line 158: /dev/null: Permission denied
/opt/zimbra/libexec/get_plat_tag.sh: line 163: /dev/null: Permission denied
/opt/zimbra/libexec/get_plat_tag.sh: line 168: /dev/null: Permission denied
/opt/zimbra/libexec/get_plat_tag.sh: line 173: /dev/null: Permission denied
/opt/zimbra/libexec/get_plat_tag.sh: line 178: /dev/null: Permission denied
/opt/zimbra/libexec/get_plat_tag.sh: line 220: dpkg: command not found
/opt/zimbra/libexec/get_plat_tag.sh: line 226: /dev/null: Permission denied
/opt/zimbra/libexec/get_plat_tag.sh: line 263: /dev/null: Permission denied 
Can't open perl script "/dev/null": Permission denied
-bash: /dev/null: Permission denied
/opt/zimbra/bin/zmswatchctl: line 45: /dev/null: Permission denied
Starting swatch.../opt/zimbra/bin/zmswatchctl: line 69: cannot redirect standard input from /dev/null: Permission denied
/opt/zimbra/bin/zmswatchctl: line 45: /dev/null: Permission denied
failed.
  • 2. The second symptom is that MTA will not start.

Cause

The problem might be caused by different things. One could be that the permissions are changed during boot time by a security software. Another cause might be that udev is missing a rule, or the rule granting rights to the /dev/null file are changed due to an upgrade of udev to systemd-tools.

Resolution

To fix the permissions, we can do the following:

  • 1) As root, delete the currently existing /dev/null:
# rm /dev/null
  • 2) Recreate it with the mknod command:
# mknod -m 0666 /dev/null c 1 3

Troubleshooting

1. We can check in /lib/udev/rules.d the 50-udev-default.rules file (CentOS release 6.7), and make sure there is a line like the following or similar if its a different distribution:

KERNEL=="null|zero|full|random|urandom", MODE="0666"

2. If that line is there, but the rights are still wrong, we can create persistent audit watch rule, in order to determine whether anything is changing /dev/null permissions after boot.

  • a) Set up a persistent audit watch in /etc/audit/audit.rules which will capture any write or attribute changes that are made to /dev/null. Include a key such as null-watch in order to easily search later for audit messages related to this rule. Please note, this rule needs to be included at some point after the -D rule at the top of that file which removes rules initially before proceeding systematically through the file.

Ideally our rule should be after the line: # Feel free to add below this line. See auditctl man page.

add the following line:

-w /dev/null -p wa -k null-watch

w - write to the file a - change in the file’s attribute

  • b) Once this is in place, restart the auditd service in order to query the rules file and initiate this watch:
service auditd restart
  • c) Check that the rule is in place:
# auditctl -l
LIST_RULES: exit,always watch=/dev/null perm=wa key=null-watch
  • d) Then check that auditing is enabled:
# auditctl -s
AUDIT_STATUS: enabled=1 flag=1 pid=1826 rate_limit=0 backlog_limit=320 lost=0 backlog=0
  • e) If not, enable auditing and ensure that the auditd service is configured to run persistently, in the appropriate run level:
auditctl -e 1
chkconfig --list auditd
  • f) Reboot the system
  • g) After the reboot, if the /dev/null has wrong permissions, check for any audit messages related to the watch using the following command:
ls -al /dev/null 
ausearch -i -k null-watch

Verified Against: Zimbra Collaboration 8.6, 8.5 Date Created: 04/22/2016
Article ID: https://wiki.zimbra.com/index.php?title=MTA_unable_to_start_due_to_wrong_/dev/null_permissions Date Modified: 2016-04-26



Try Zimbra

Try Zimbra Collaboration with a 60-day free trial.
Get it now »

Want to get involved?

You can contribute in the Community, Wiki, Code, or development of Zimlets.
Find out more. »

Looking for a Video?

Visit our YouTube channel to get the latest webinars, technology news, product overviews, and so much more.
Go to the YouTube channel »


Wiki/KB reviewed by Teodor SME2 Copy Editor Last edit by Jorge de la Cruz
Jump to: navigation, search