Bug 67280

Summary:	[RFE] be more picky about mount points (/. /.. etc)
Product:	[Retired] Red Hat Linux	Reporter:	James Manning <jmm>
Component:	anaconda	Assignee:	Jeremy Katz <katzj>
Status:	CLOSED WONTFIX	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	low
Version:	9	CC:	gt
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-10-05 02:42:12 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description James Manning 2002-06-21 20:20:48 UTC

summary sez it all - i was allowed to pick /. and /.. as mount points (i'm sure
i could have done /home and /home/. as sep. filesystems as well, for instance).
 it'd be nice if the validation check noticed directory components of "." or
".." and handled that

Comment 1 Michael Fulbright 2002-06-26 05:30:16 UTC

Will do.

Comment 2 Michael Fulbright 2002-06-26 05:36:10 UTC

I addressed this simple case with periods.

Do you know of a definative list of what is accepted and what is not?

Comment 3 James Manning 2002-06-26 05:54:50 UTC

disallowing periods altogether is definitely one approach - I was thinking more
about an approach that would basically do a sanity check on a path by split'ing
itinto an array based on / and if any of the components came out to "." or ".."
then change the path appropriately (just remove the element if it's "." or
remove it and any preceding element for "..")  Once the path's basically
resolved to its canonical form (python's prob. got a better approach for getting
to this canonical form) then this can be the new value in the mount point field
and compared with the mount points of other filesystems.

again, disallowing periods altogether is a possible solution, but one that'd be
overkill since it'd end up disallowing lots of very valid and useful mount
points (like if people do like /home.devel, /home.biz, /home.hr)

course, I may be misunderstanding the question :)

Comment 4 James Manning 2002-06-26 15:43:57 UTC

if it's avail, it looks like os.path.normpath could be a definite help

% python -c 'import os;print os.path.normpath("/home/../usr/.//foo")'
/usr/foo

then just check path vs. normpath(path) and if diff reset the value of the
mountpoint dialog to the result?

Comment 5 Robert P. J. Day 2002-07-17 19:37:59 UTC

  as it stands, anaconda *does* reject mount point names with periods.
i just tried to create one with the name "/7.3" and got refused.  but
"/73" was fine.  periods should definitely be acceptable.

Comment 6 James Manning 2002-07-17 22:50:27 UTC

um, yes, msf said he was disallowing periods in the june 26th comment on this 
bug.  Hence, why I'd rather do what I had recommended in using the normpath 
results, where /. and /.. and all that crap would get filtered out smartly.  
Disallowing periods is, I agree, a bad thing :/

Hopefully msf/katzj can get back to this bug entry soon, but they're pretty 
overloaded, of course ...

Comment 7 Jeremy Katz 2002-08-19 19:01:26 UTC

Will address in a future release

Comment 8 Gerald Teschl 2003-01-20 19:50:55 UTC

If it is a valid mount point, then anaconda should accept it.
I noted that ks will do it, but pop up an ok box before doing
so. This makes ks interactive;-( Could you please fix the check
or at least skip it during ks.

Comment 9 Jeremy Katz 2004-10-05 02:42:12 UTC

We've made things a little better, but not going to allow everything.
 Have to have some limits of sanity here.