Bug 214980 - /etc/init.d/autofs does not handle basedns with spaces
/etc/init.d/autofs does not handle basedns with spaces
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: autofs (Show other bugs)
4.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Brock Organ
:
Depends On:
Blocks: 234251 350171
  Show dependency treegraph
 
Reported: 2006-11-10 08:37 EST by Bryn M. Reeves
Modified: 2010-10-22 02:54 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2007-0734
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-15 11:02:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch adding support for basedns with spaces (1.23 KB, patch)
2006-11-10 08:37 EST, Bryn M. Reeves
no flags Details | Diff
Configuration files (1.57 KB, application/x-compressed)
2007-07-16 17:24 EDT, Bryan Mason
no flags Details

  None (edit)
Description Bryn M. Reeves 2006-11-10 08:37:53 EST
The autofs initscript incorrectly parses mounts when the LDAP basedn contains
spaces, causing the affected mounts to fail.

The attached patch is based in part on changes that are already part of upstream
autofs.
Comment 1 Bryn M. Reeves 2006-11-10 08:37:55 EST
Created attachment 140885 [details]
Patch adding support for basedns with spaces
Comment 2 RHEL Product and Program Management 2006-11-10 09:03:31 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 3 Jeffrey Moyer 2006-11-13 12:30:26 EST
Bryn,

My bash scripting isn't "guru" level, so could you please explain the patch a
little to me?  Additionally, it would be quite helpful for myself and QA if you
would include the maps that failed without this patch.  You nuked the entire
template for filing a bug report that bugzilla provides;  it has really useful
information in it like, steps to reproduce.  Please include these.

Also, who tested this patch and how?
Comment 5 Bryn M. Reeves 2006-11-16 06:46:50 EST
Jeff,

Sorry for the brevity of the description. The history of this change goes like this:

Upstream autofs-4.1.3 contains this in rc.autofs.in:

function redhat()
{
...
        TMP=`mktemp /tmp/autofs.XXXXXX` || { echo $"could not make temp file" >&
2; exit 1; }
        getmounts | tee $TMP | sh
        RETVAL=$?
...
}

This was changed in the RHEL4 autofs package by
autofs-4.1.3-init-daemon-exit-status.patch:

-        getmounts | tee $TMP | sh
-        RETVAL=$?
-       if [ -s $TMP ] ; then
-           if [ $RETVAL -eq 0 ] ; then
-               success "$prog startup"
-           else
+
+       getmounts | tee $TMP | (
+           WARN=0
+           SUCCESS=0
+           while read cmd rest
+           do
+               $cmd $rest >&/dev/null

So, instead of piping the commands straight into a shell, they are piped via a
subshell that reads them in a loop and executes them directly.

Although these two are close, it seems that they treat whitespace/quoting
differently.

The attached patch restores the "| sh" within the loop that consumes the output
of the "getents | tee" pipeline. This should still give the correct exit status
in  RETVAL since the exit status of sh will be carried down.

Upstream autofs-4.1.4 also has the "getmounts | tee $TMP | sh" pipeline.

The remaining changes, I'm less sure about - changing the mktemp patterns seems
unnecessary (mktemp is smart enough to avoid a collision here anyway).

+	getmounts | sed 's/"//g' >$TMP1

Just strips quotes from the output of getmounts.

I have tested that the modified script still works correctly for non-LDAP maps.
The reporter has tested with LDAP mounts and reports that the script now works
correctly for BaseDns that contain embedded spaces.

An example BaseDn that triggers this problem would be:

/data ldap:anldap:"nisMapName=auto.data,ou=automount,ou=application
services,ou=some department,o=acme,c=us" -intr,noquota

Steps to reproduce:

1. Configure an LDAP automounter map as above with spaces in the BaseDn
2. Attempt to start or reload autofs
3. Attempt to access the filesystems in the LDAP map

Actual results:

The autofs script does not correctly parse the LDAP BaseDn and filesystems are
not mounted automatically when accessed.

Expected results:

A BaseDn containing embedded spaces is parsed correctly & filesystems can be
mounted as normal.
Comment 7 Jeffrey Moyer 2006-11-16 09:25:14 EST
Bryn,

Thanks a bunch!  That is a great description and will aid me quite a bit in
regression testing.

-Jeff
Comment 8 Jeffrey Moyer 2007-01-12 16:51:04 EST
Autofs versions 4.1.3-202 and later include a fix for this issue.  Please test
this package out when you get a chance.

Thanks!
Comment 11 RHEL Product and Program Management 2007-05-09 04:56:05 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 13 Jeffrey Moyer 2007-07-13 15:55:11 EDT
Bryn, have you had a chance to test the updated package?  Can you please do so?
Comment 15 Bryan Mason 2007-07-16 17:24:34 EDT
Created attachment 159378 [details]
Configuration files

Hi Jeff - it looks like this may not have been fixed.  Although I'm not sure of
the customer's exact configuration, I've configured my system to use spaces in
part of the DN used by autofs, and it fails to load.

My system configuration is as follows:

1) autofs-4.1.3-218.x86_64
2) kernel 2.6.9-55.EL
3) autofs maps - see LDIF file in attached tarball
4) nsswitch - see nsswitch.conf in attached tarball
5) autofs config - see autofs in attached tarball
6) debug output - none.  /var/log/messages shows

       Jul 16 14:16:30 why autofs: automount startup succeeded

   but there's nothing in /var/log/debug.log.
Comment 16 Bryan Mason 2007-07-16 17:28:31 EDT
One additional note.  If I comment out the assignment for BASEDN in
/etc/sysconfig/autofs, I get the following message on the console:

# service autofs start
Starting automount: failed to load map, exiting
failed to load map: /usr/sbin/automount --debug --use-old-ldap-lookup /tmp/ldap
ldap nisMapName=auto.ldap,ou=auto -DUSER=bjmason
mount,dc=bjmason,dc=sfbay,dc=redhat,dc=com
                                                           [FAILED]

and the following messages in /var/log/debug.log:

Jul 16 14:24:51 why automount[29605]: starting automounter version 4.1.3-218, pa
th = /tmp/ldap, maptype = ldap, mapname = nisMapName=auto.ldap,ou=auto
Jul 16 14:24:51 why automount[29605]: lookup(ldap): server = "(default)", port =
 389, base dn = "nisMapName=auto.ldap,ou=auto"
Jul 16 14:24:51 why automount[29605]: parse(sun): init gathered options: mount,d
c=bjmason,dc=sfbay,dc=redhat,dc=com
Jul 16 14:24:51 why automount[29605]: mount(bind): bind_works = 1 
Jul 16 14:24:51 why automount[29605]: using kernel protocol version 4.00
Jul 16 14:24:51 why automount[29605]: using timeout 300 seconds; freq 75 secs
Jul 16 14:24:51 why automount[29605]: lookup(ldap): searching for "(objectclass=
nisObject)" under "nisMapName=auto.ldap,ou=auto"
Jul 16 14:24:51 why automount[29605]: lookup(ldap): query failed for (objectclas
s=nisObject)
Jul 16 14:24:51 why automount[29605]: lookup(ldap): searching for "(objectclass=
automount)" under "nisMapName=auto.ldap,ou=auto"
Jul 16 14:24:51 why automount[29605]: lookup(ldap): query failed for (objectclas
s=automount)
Jul 16 14:24:51 why automount[29605]: lookup(ldap): searching for "(objectclass=
automount)" under "nisMapName=auto.ldap,ou=auto"
Jul 16 14:24:51 why automount[29605]: lookup(ldap): query failed for (objectclas
s=automount)
Jul 16 14:24:51 why automount[29605]: failed to load map, exiting
Jul 16 14:24:51 why automount[29605]: rm_unwanted: unable to remove directory:  
/tmp/ldap, error: Device or resource busy
Jul 16 14:24:51 why automount[29605]: umount_multi: path=/tmp/ldap incl=0
Comment 17 Jeffrey Moyer 2007-07-16 23:59:28 EDT
nisMapEntry: ldap:nisMapName=auto.ldap,ou=auto
mount,dc=bjmason,dc=sfbay,dc=redhat,dc=com

Autofs requires that the spaces be quoted.  Try this, instead:

nisMapEntry: ldap:"nisMapName=auto.ldap,ou=auto
mount,dc=bjmason,dc=sfbay,dc=redhat,dc=com"

Specifying the BASEDN in /etc/sysconfig/autofs is proving problematic for this
case.  It seems that no matter what I do, the shell is inserting single quotes,
making each space-separated token into a separate argument.  I'll try to work
through that.  The worst case scenario is that extra logic would be needed in
the autofs-ldap-auto-master command line parsing to deal with the base dn with
spaces.
Comment 18 Jeffrey Moyer 2007-07-17 12:45:02 EDT
OK, I modified the init script to handle spaces in BASEDN, as specified in
/etc/sysconfig/autofs.  You should be using double quotes to specify that variable:

BASEDN="ou=test with spaces,dc=example,dc=com"

The fix appears in autofs-4.1.3-221.  Please have the customer test with this
package.

Thanks.
Comment 19 Bryan Mason 2007-07-17 13:48:12 EDT
This works fine for me now.  I'll pass along the updated packages to the
customer for further testing.
Comment 23 errata-xmlrpc 2007-11-15 11:02:00 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0734.html

Note You need to log in before you can comment on or make changes to this bug.