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

(MTA unable to start due to wrong /dev/null permissions)
(MTA unable to start due to wrong /dev/null permissions)
Line 38: Line 38:
  
 
2. The second symptom is that MTA will not start.  
 
2. The second symptom is that MTA will not start.  
 
+
---
 
 
 
===Cause===
 
===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.  
 
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.  
 
+
---
 
===Troubleshooting===
 
===Troubleshooting===
  
Line 51: Line 50:
 
2. Can create persistent audit watch rule, in order to determine whether anything is changing /dev/null permissions after boot.
 
2. 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 after the line: "# Feel free to add below this line. See auditctl man page".
+
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".
  
 
add the following line:
 
add the following line:
Line 76: Line 76:
 
  ls -al /dev/null  
 
  ls -al /dev/null  
 
  ausearch -i -k null-watch
 
  ausearch -i -k null-watch
 
+
---
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
===Resolution===
 
===Resolution===
  
------------------
+
To fix the permissions, we can do the following:  
Since UDEV isn't correctly changing the permissions for the current /dev/null, it might be possible to try re-creating /dev/null using the mknod command.
 
 
 
As root, delete the currently existing /dev/null:
 
 
 
Raw
 
# rm /dev/null</code>
 
Recreate it with the mknod command:
 
  
Raw
+
1) As root, delete the currently existing /dev/null:
# mknod -m 0666 /dev/null c 1 3
+
# rm /dev/null</code>
The /dev/null file should now have with the correct permissions.
 
  
If the problem persists after a reboot, then follow the steps in the 'Diagnostic Steps' section of this article, in order to set up an audit watch which may help determine whether /dev/null permissions are being changed after boot.
+
2) Recreate it with the '''mknod''' command:
 +
# mknod -m 0666 /dev/null c 1 3

Revision as of 11:29, 22 April 2016

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

   KB 22604        Last updated on 2016-04-22  




0.00
(0 votes)


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
-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 is changed due to an upgrade of udev to systed-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:

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.

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

add the following line:

-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:

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

---

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
Jump to: navigation, search