Bug 67280 - [RFE] be more picky about mount points (/. /.. etc)
Summary: [RFE] be more picky about mount points (/. /.. etc)
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 9
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-06-21 20:20 UTC by James Manning
Modified: 2007-03-27 03:54 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-10-05 02:42:12 UTC
Embargoed:


Attachments (Terms of Use)

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.


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