Bug 2413 - getmntent() returns invalid, not existent paths in mntent.mnt_dir
Summary: getmntent() returns invalid, not existent paths in mntent.mnt_dir
Status: NEW
Alias: None
Product: uClibc
Classification: Unclassified
Component: Standard Compliance (show other bugs)
Version: 0.9.30.3
Hardware: All Linux
: P5 major
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-18 13:20 UTC by A.Mazur
Modified: 2015-04-16 08:06 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:


Attachments
Fix (1.08 KB, patch)
2010-08-18 13:23 UTC, A.Mazur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description A.Mazur 2010-08-18 13:20:50 UTC
getmntent() fills mntent.mnt_dir with a value directly obtained from /proc/mounts file, without processing octal escapes.
This results in returning non-existent path names for file systems which are mounted in paths that contain whitespace characters. And, for example, this causes the `df' applet from busybox to fail for such filesystems.
getmntent(3) linux man page says:

> Since fields in the mtab and fstab files are separated by whitespace, octal
> escapes are used to represent the four characters space (\040), tab (\011),
> newline (\012) and backslash (\134) in those files when they occur in one of
> the four strings in a mntent structure. The routines addmntent() and getmntent()
> will convert from string representation to escaped representation and back. 

So applications may just assume that mntent.mnt_dir contains a valid, existing path to the mount directory which may be used directly.
Comment 1 A.Mazur 2010-08-18 13:23:21 UTC
Created attachment 2353 [details]
Fix
Comment 2 Joao Cardoso 2010-12-11 16:51:57 UTC
Any reason to not apply the fix also to the mnt_fsname field?

I have done it and tested with nfs and cifs having spaces in the path, and it works on uClibc-0.9.30.3.
Comment 3 Bernhard Reutner-Fischer 2011-02-09 20:23:33 UTC
addmntent, getmntent encoding parts are unfortunately missing.
Also, according to the manpage you cite, glibc seems to only encode a few octal values, not all.

Please submit a proper, tested patch. See uclibc.org/FAQ.html#contrib