RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 666340 - autofs handle isspace() char incorrectly
Summary: autofs handle isspace() char incorrectly
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: autofs
Version: 6.0
Hardware: Unspecified
OS: Unspecified
low
high
Target Milestone: rc
: ---
Assignee: Ian Kent
QA Contact: yanfu,wang
URL:
Whiteboard:
Depends On:
Blocks: 668354
TreeView+ depends on / blocked
 
Reported: 2010-12-30 09:13 UTC by John Lau
Modified: 2018-11-14 15:55 UTC (History)
2 users (show)

Fixed In Version: autofs-5.0.5-26.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 668354 (view as bug list)
Environment:
Last Closed: 2011-05-19 14:22:54 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Escape the isspace() char no matter there is space or not (1.28 KB, application/octet-stream)
2010-12-30 09:13 UTC, John Lau 		no flags Details
Patch - fix isspace() wild card substition (1.96 KB, patch)
2011-01-10 12:51 UTC, Ian Kent 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0753 0 normal SHIPPED_LIVE autofs bug fix update 2011-05-18 18:08:57 UTC

Description John Lau 2010-12-30 09:13:26 UTC 
Created attachment 471158 [details]
Escape the isspace() char no matter there is space or not

Description of problem:
A customer found a strange behaviour of autofs when using &-expand Sun-style map. For example, if I have the following directory in NFS server:

/export/rhel5

And the /etc/exports file is:

/export		*(rw,no_root_squash,sync)

Then we have a /etc/auto.misc file in client:

*		-ro,intr,noacl		127.0.0.1:/export/&

Then I access the autofs and look for a "/misc/rhel5\n" directory (by write a C code and use chdir()), autofs will create a "rhel5\n" directory and mount the "rhel5" directory. What I expect is that it should fail because there is no "rhel5\n" directory.

After I study the code, I found that problem is related to parse_mount() in parse_sun.c. It will:

1. parse_sun.c:1398 use expandsunent function to append the key (directory name) to the dst (mount path). And it will escape all the isspace() char when there is any *space* in the key.
2. parse_sun.c:1659 dequote function will remove the escape code and the return path will be used to mount the nfs.

So if the key (directory name) don't have a space, it will not escape any other isspace() char (\n, \r, \t, etc). And then the mount path will not be processed correctly by dequote function. In my example, it will be trim to be "127.0.0.1:/export/rhel5".

Also if there is a directory like "rhel5\tx86" in the NFS server, it will not be able to mount by autofs successfully because of this bug, while "rhel 5\tx86" will be processed correctly because it has a space.


Version-Release number of selected component (if applicable):
autofs-5.0.5-23.el6 (The same issue also happens on autofs on Fedora 14)

How reproducible:
100%

Steps to Reproduce:
1. Create a "rhel5" directory in a NFS export directory
2. Config autofs to use &-expand Sun-style map
3. Write a C program to access "rhel5\n" directory by chdir()
  
Actual results:
There will be a "rhel5\n" directory in client and it will mount the "rhel5" directory of the server

Expected results:
It will report fail because there is no "rhel5\n" directory
Comment 4 Ian Kent 2011-01-10 11:06:50 UTC 
(In reply to comment #0)
> Created attachment 471158 [details]
> Escape the isspace() char no matter there is space or not
> 
> Description of problem:
> A customer found a strange behaviour of autofs when using &-expand Sun-style
> map. For example, if I have the following directory in NFS server:
> 
> /export/rhel5
> 
> And the /etc/exports file is:
> 
> /export  *(rw,no_root_squash,sync)
> 
> Then we have a /etc/auto.misc file in client:
> 
> *  -ro,intr,noacl  127.0.0.1:/export/&
> 
> Then I access the autofs and look for a "/misc/rhel5\n" directory (by write a C
> code and use chdir()), autofs will create a "rhel5\n" directory and mount the
> "rhel5" directory. What I expect is that it should fail because there is no
> "rhel5\n" directory.
> 
> After I study the code, I found that problem is related to parse_mount() in
> parse_sun.c. It will:
> 
> 1. parse_sun.c:1398 use expandsunent function to append the key (directory
> name) to the dst (mount path). And it will escape all the isspace() char when
> there is any *space* in the key.
> 2. parse_sun.c:1659 dequote function will remove the escape code and the return
> path will be used to mount the nfs.
> 
> So if the key (directory name) don't have a space, it will not escape any other
> isspace() char (\n, \r, \t, etc). And then the mount path will not be processed
> correctly by dequote function. In my example, it will be trim to be
> "127.0.0.1:/export/rhel5".
> 
> Also if there is a directory like "rhel5\tx86" in the NFS server, it will not
> be able to mount by autofs successfully because of this bug, while "rhel
> 5\tx86" will be processed correctly because it has a space.

Handling white space and other characters that are considered
map entry segment terminators is a bit of a nightmare in autofs.

So, while I acknowledge this is a bug, I'm not clear on what we
should do about it. Some testing does show that quoting in the
above cases is not working properly but any change that I make
is probably not going to be what you're expecting.

So what exactly is the behaviour you are hoping to see, given
that white space and other map entry segment terminator characters
can't just be placed in a key string without quoting, even if it
was being handled properly?

You may need to skim over the "map entry segment terminator
characters" statement above to start with, if you don't mind,
while we work out where we want to get to with this.

Ian
Comment 5 Ian Kent 2011-01-10 12:51:48 UTC 
Created attachment 472578 [details]
Patch - fix isspace() wild card substition

Maybe I'm making this much more complicated than it needs to be.

After re-reading your comments and looking again at the code I
think this patch is more like what you are trying to get at.

Is this more like it?
Comment 6 Ian Kent 2011-01-10 12:55:01 UTC 
(In reply to comment #5)
> Created attachment 472578 [details]
> Patch - fix isspace() wild card substition
> 
> Maybe I'm making this much more complicated than it needs to be.
> 
> After re-reading your comments and looking again at the code I
> think this patch is more like what you are trying to get at.
> 
> Is this more like it?

Mmm ... but I think that's not the whole story either.

That const char *keyp will break if we have more than one &
substitution, ;)

Nevertheless this is hopefully on the right track.
Comment 7 Ian Kent 2011-01-11 03:15:33 UTC 
(In reply to comment #6)
> (In reply to comment #5)
> > Created attachment 472578 [details]
> > Patch - fix isspace() wild card substition
> > 
> > Maybe I'm making this much more complicated than it needs to be.
> > 
> > After re-reading your comments and looking again at the code I
> > think this patch is more like what you are trying to get at.
> > 
> > Is this more like it?
> 
> Mmm ... but I think that's not the whole story either.
> 
> That const char *keyp will break if we have more than one &
> substitution, ;)
> 
> Nevertheless this is hopefully on the right track.

Mmm ... looking again today I noticed you provided a patch
which is largely the same as what I have posted, sorry I
didn't notice it yesterday. The formatting in my version
is more to my liking so I'll use it instead of yours.

Now, we just need some acks.

Ian
Comment 9 yanfu,wang 2011-03-03 03:22:42 UTC 
verified against new package with autofs regression testsuite:
i386: https://beaker.engineering.redhat.com/jobs/57086
x86_64: https://beaker.engineering.redhat.com/jobs/57463
ppc64: https://beaker.engineering.redhat.com/jobs/57948
s390x: https://beaker.engineering.redhat.com/jobs/57949
Comment 10 errata-xmlrpc 2011-05-19 14:22:54 UTC 
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 therefore 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-2011-0753.html
Note You need to log in before you can comment on or make changes to this bug.