Bug 1163957

Summary: Autofs unable to mount indirect after attempt to mount wildcard
Product: Red Hat Enterprise Linux 6 Reporter: Frank Sorenson <fsorenso>
Component: autofsAssignee: Ian Kent <ikent>
Status: CLOSED ERRATA QA Contact: XuWang <xuw>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.6CC: djeffery, eguan, ikent, plambri, xuw
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: autofs-5.0.5-110 Doc Type: Bug Fix
Doc Text:
Cause: when an "ls *" is done of the root of an indirect mount, autofs will attempt to literally mount the key '*' causing it to be added to the negative cache. Consequence: if this is done before a valid mount, autofs fails on further mount attempts inside the mountpoint, valid or not. Fix: fixed by checking for and not adding the wildcard key when updating the negative cache. Result: the wildcard map entry continues to function following a 'ls *' within the root of an autofs mountpoint.
Story Points: ---
Clone Of:
: 1166457 1170887 (view as bug list) Environment:
Last Closed: 2015-07-22 06:51:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1166457, 1170887    
Attachments:
Description Flags
Patch - make negative cache update consistent for all lookup modules
none
Patch - ensure negative cache isn't updated on remount
none
Patch - dont add wildcard to negative cache none

Description Frank Sorenson 2014-11-13 19:29:38 UTC
Description of problem:

When an "ls *" is done of the root of an indirect mount, autofs will attempt to literally mount the key '*'.  If this occurs before a valid mount key, autofs will fail on any further mount attempts inside the mountpoint, valid or not.


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

automount version 5.0.5-109.el6
RHEL 6.6


How reproducible:

easy

Steps to Reproduce:
1. mkdir -p /auto_test/dir{1,2}
2. echo "/auto_test/mounts    /etc/auto.test" > /etc/auto.master
3. echo "*    -fstype=bind    :/auto_test/&" > /etc/auto.test
4. /etc/init.d/autofs restart
5. ls -ld /auto_test/mounts/*
6. ls -ld /auto_test/mounts/dir{1,2}

Actual results:

# ls -ld /auto_test/mounts/*
ls: cannot access /auto_test/mounts/*: No such file or directory

# ls -ld /auto_test/mounts/dir{1,2}
ls: cannot access /auto_test/mounts/dir1: No such file or directory
ls: cannot access /auto_test/mounts/dir2: No such file or directory


Expected results:

# ls -ld /auto_test/mounts/*
ls: cannot access /auto_test/mounts/*: No such file or directory

# ls -ld /auto_test/mounts/dir{1,2}
drwxr-xr-x 2 root root 4096 Nov 13 18:02 /auto_test/mounts/dir1
drwxr-xr-x 2 root root 4096 Nov 13 18:02 /auto_test/mounts/dir1

# ls -ld /auto_test/mounts/*
drwxr-xr-x 2 root root 4096 Nov 13 18:02 /auto_test/mounts/dir1
drwxr-xr-x 2 root root 4096 Nov 13 18:02 /auto_test/mounts/dir2


Additional info:

This problem only occurs when the wildcard ("*") is attempted before a successful automount occurs.

Other invalid keys will give the expected "No such file or directory" error, but valid mounts will still succeed afterwards.

Once a valid mount occurs, the wildcard failure will produce the error, but valid mounts will continue to work.

Comment 2 Ian Kent 2014-11-14 04:45:35 UTC
Yes, that's not good.
I'll investigate and see what I can do about it.

Ian

Comment 3 Ian Kent 2014-11-19 01:43:09 UTC
(In reply to Ian Kent from comment #2)
> Yes, that's not good.
> I'll investigate and see what I can do about it.

Looks like the wildcard is being added as a negative cache
entry which prevents any further wildcard lookup matching.

I'll make a patched rpm for testing.

Comment 4 Ian Kent 2014-11-19 06:59:05 UTC
Created attachment 958895 [details]
Patch - make negative cache update consistent for all lookup modules

Comment 5 Ian Kent 2014-11-19 07:00:08 UTC
Created attachment 958896 [details]
Patch - ensure negative cache isn't updated on remount

Comment 6 Ian Kent 2014-11-19 07:01:06 UTC
Created attachment 958897 [details]
Patch - dont add wildcard to negative cache

Comment 7 Ian Kent 2014-11-19 07:02:32 UTC
An autofs build with the above three patches is available at:
http://people.redhat.com/~ikent/autofs-5.0.5-110.el6/

This should resolve the problem seen here.
Please test in your environment.

Comment 8 Pierguido Lambri 2014-11-19 10:06:34 UTC
I can confirm it works with the new package:

# cd *                       
-bash: cd: *: No such file or directory
# cd test1
# pwd
/home2/test1

Before the new package:

# cd *
-bash: cd: *: No such file or directory
# cd test1
-bash: cd: test1: No such file or directory

Comment 12 XuWang 2015-03-16 08:05:55 UTC
Reproduced on RHEL-6.6-20140926.0, with autofs  with autofs-5.0.5-112, results like following:
:: [  BEGIN   ] :: Running 'ls -ld /automount/*'
ls: cannot access /automount/*: No such file or directory
:: [   PASS   ] :: Command 'ls -ld /automount/*' (Expected 2, got 2)
:: [  BEGIN   ] :: Running 'ls -ld /automount/dir{1,2}'
ls: cannot access /automount/dir1: No such file or directory
ls: cannot access /automount/dir2: No such file or directory
:: [   FAIL   ] :: Command 'ls -ld /automount/dir{1,2}' (Expected 0, got 2)

Verified on RHEL-6.7-20150304.0, with autofs-5.0.5-112, covers i386, x86_64, s390x, ppc64, results like following:
[04:53:42 root@ ~~]# ls -ld /automount/*
ls: cannot access /automount/*: No such file or directory
:: [   PASS   ] :: Running 'ls -ld /automount/*' (Expected 2, got 2)
--------------------------------------------------------------------------------
[04:53:42 root@ ~~]# ls -ld /automount/dir{1,2}
drwxr-xr-x. 2 root root 4096 Mar 12 04:53 /automount/dir1
drwxr-xr-x. 2 root root 4096 Mar 12 04:53 /automount/dir2
:: [   PASS   ] :: Running 'ls -ld /automount/dir{1,2}' (Expected 0, got 0)

Also run regression/bugzillas/stress tests for autofs-5.0.5-112, works fine.
So I change this bug status to be VERIFIED.

Comment 13 errata-xmlrpc 2015-07-22 06:51:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-1344.html