Note: This is an archival copy of Security Sun Alert 200510 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1000388.1.
Solaris 9 Operating System
Solaris 7 Operating System
Solaris 8 Operating System
Date of Resolved Release
A local unprivileged user may be able to create a denial of service by killing the automountd(1M) daemon. This would affect all applications that utilize autofs(4) file systems which are automatically mounted by the automountd(1M) daemon.
This issue can occur in the following releases:
Note: Solaris 10 does not have Federated Naming Services (FNS) and is not impacted by this issue.
The described issue only occurs if all of the following conditions are true:
To determine if FNS support for X.500 directory context is installed, the following command can be run:
$ pkginfo SUNWfnsx5 system SUNWfnsx5 FNS Support For X.500 Directory Context
To determine if FNS is enabled in "/etc/auto_master", the following command can be run:
$ grep /xfn /etc/auto_master /xfn -xfn
To determine if autofs(4) is installed and started at boot, the following command can be run:
$ pkginfo SUNWatfsu system SUNWatfsu AutoFS, (Usr) $ ls /etc/rc2.d/S74autofs /etc/rc2.d/S74autofs
To determine if FNS X.500 configuration references a valid LDAP server, the following command can be run:
$ grep ldap /etc/fn/x500.conf # x500-access: <ordered list of "xds" and/or "ldap"> # ldap-servers: <ordered list of hostnames and/or IP addresses> x500-access: xds ldap ldap-servers: localhost ldap $ getent hosts ldap 184.108.40.206 ldap.sun.com
Note: This issue is very rarely encountered even on systems that meet all of the conditions listed above.
If the described issue occurs, the automountd(1M) process is absent. This can be seen by using the pgrep(1m) command:
$ pgrep automountd || echo "automountd process NOT found!"
In general, processes or applications attempting to access files or directories that rely on autofs(4) may fail with error messages such as "no such file or directory" or "does not exist". As an example, the Bourne shell (/usr/bin/sh) attempting to change directory to a known autofs(4) path would result in the following:
$ cd /share/local /share/local: does not exist
To work around the described issue, one of the following options can be applied:
Restart automountd(1M) using the following command as root:
# pgrep automountd || /etc/init.d/autofs start
The following simple Bourne script will check and restart automountd(1M) as necessary:
# while pgrep automountd || /etc/init.d/autofs start; do sleep 10; done
If FNS X.500 is not intended to be used with LDAP, remove the server name "ldap" from the "/etc/fn/x500.conf" file.
Remove the "/xfn" entry from the "auto_master" mapfile (either in files or NIS, NIS+, or LDAP).
If FNS is not being used, remove the FNS packages:
SUNWfns Federated Naming System SUNWfnsx Federated Naming System (64-bit) SUNWfnsx5 FNS Support For X.500 Directory Context
Refer to the pkgrm(1M) command for additional information on removing packages.
This issue is addressed in the following releases:
This solution has no attachment