Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 176627 - Multimounts containing multiple automounts of implicit map type fail
Multimounts containing multiple automounts of implicit map type fail
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Moyer
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2005-12-27 16:47 EST by Ian McLeod
Modified: 2008-08-02 19:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-17 14:58:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
fix the parser to not choke on the absence of a colon in a multimount entry (347 bytes, patch)
2006-01-06 16:45 EST, Jeff Moyer
no flags Details | Diff
Attempt to fix incorect parsing when colon is not present (1.08 KB, patch)
2006-01-10 09:40 EST, Ian Kent
no flags Details | Diff

  None (edit)
Description Ian McLeod 2005-12-27 16:47:53 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041215 Firefox/1.0 Red Hat/1.0-12.EL4

Description of problem:
Multimounts fail due to a parsing error if they contain multiple nested "sub-automounts" that don't use the "<type>:<mapname>" to explicitly indicate map type.  For example, the following submount will fail:

submountdir / server:/mountpoint \
  /nestedmount1 -fstype=autofs auto.nested1 \
  /nestedmount2 -fstype=autofs auto.nested2

This will produce the following error when you attempt to enter "submountdir"

"nsswitch: unable to find map, auto.nested1               /nestedmount2 -fstype=autofs auto.nested2 in domain, mydomain.com"

As best I can tell, this occurs because the multimount parsing code assumes that the source for a multimount must contain a colon.  As a result, it calls the internal "chunklen" function with the "expect colon" value set to true.  This causes the parser to ignore all tabs and spaces, processing the remainder of the line as if it were the map source (producing the error message above).

This assumption works if the source is an actual NFS share, or if it is a sub-automount with an explicitly indicated type.  It fails if the sub-automount has no explicit type.

(Note that the code to use nsswitch to find an implicit map _does_ work just fine.)

I've attached a patch that fixes this particular case.  However, I suspect it will still fail on more complex multimounts that combine sub-automounts with NFS shares.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create file maps to duplicate the map structure described above
2. Attempt to enter the submountdir directory

Actual Results:  Error message in syslog as described above

Expected Results:  server:/mountpoint should be mounted on "submountdir" 

Two sub-automounts should be started

Additional info:
Comment 2 Jeff Moyer 2006-01-06 16:45:05 EST
Created attachment 122894 [details]
fix the parser to not choke on the absence of a colon in a multimount entry

After discussing this with Ian, we've agreed that the caller in question should
never set expect_colon to 1.  This patch affects that change, and is currently
being tested.
Comment 3 Ian Kent 2006-01-10 09:40:22 EST
Created attachment 122998 [details]
Attempt to fix incorect parsing when colon is not present 

Hi Ian,

Could you test this patch please.

Comment 4 Jeff Moyer 2006-04-19 12:26:19 EDT
Ian M., have you had a chance to try out Ian K.'s patch?
Comment 5 Jeff Moyer 2006-05-23 13:23:33 EDT
Ian M, any news?
Comment 6 Jeff Moyer 2006-08-08 15:21:43 EDT
Ian M., are you alive?
Comment 10 Jeff Moyer 2007-01-17 14:58:25 EST
I'm closing this as WONTFIX, since the reporter is no longer responsive, and
because it does not seem to fit the RHEL 3.9 release criteria.

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