This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 67280 - [RFE] be more picky about mount points (/. /.. etc)
[RFE] be more picky about mount points (/. /.. etc)
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
9
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-21 16:20 EDT by James Manning
Modified: 2007-03-26 23:54 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-04 22:42:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description James Manning 2002-06-21 16:20:48 EDT
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 01:30:16 EDT
Will do.
Comment 2 Michael Fulbright 2002-06-26 01:36:10 EDT
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 01:54:50 EDT
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 11:43:57 EDT
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 15:37:59 EDT
  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 18:50:27 EDT
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 15:01:26 EDT
Will address in a future release
Comment 8 Gerald Teschl 2003-01-20 14:50:55 EST
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-04 22:42:12 EDT
We've made things a little better, but not going to allow everything.
 Have to have some limits of sanity here.

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