classification
Title: file:// scheme will stop accessing via ftp protocol
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.2
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: orsenthil Nosy List: eric.araujo, orsenthil, pitrou, r.david.murray
Priority: normal Keywords: patch

Created on 2010-10-10 09:40 by orsenthil, last changed 2010-10-14 11:58 by orsenthil. This issue is now closed.

Files
File name Uploaded Description Edit
file_scheme.diff orsenthil, 2010-10-10 09:40
Messages (13)
msg118327 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-10-10 09:40
file:// scheme should not be allowed to access a file on remote machines.  RFC 1738, says that host, if present should be the FQDN of the machine, but relaxing on that I thinking that localhost and its variants should okay as long as it is the local machine.

What is going to break in 3.2 is file:// trying to access resources on remote machine via FTP, which it is currently trying to do.

Attached is patch to accomplish this.(NEWS and Docs will be added).

This would introduce a regression, so this may not be backported.
msg118335 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-10-10 15:49
Does it also need a deprecation cycle?
msg118347 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-10-11 06:32
On Sun, Oct 10, 2010 at 03:49:42PM +0000, R. David Murray wrote:
> Does it also need a deprecation cycle?

I think, adding a deprecation cycle might just delay this change.
So, I would prefer if we make it in the 3.2 itself.

- This is not a user-facing API change and I did not see any
  references where people relied upon this behavior. (No bugs / usage
  cases)
- It is actually a bug, because one may not be sure if the ftp service
  is running the machine in the first place and user may not intend
  that ftp service be used for accessing local resources.

We had python-dev discussion on this sometime back when fixing another
bug and conclusion was that we raise a ValueError when file:// scheme
was used in non-local url. Instead of ValueError, I think the generic
URLError is okay too.
msg118361 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-10-11 14:17
If it's been reviewed on python-dev and the consensus was to turn it into an error in 3.2, then I'm fine with it.  But I'll bet we'll get at least a few bug reports :)
msg118431 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-10-12 16:40
file: URIs provoking FTP access seem wrong to me.  Are there widely-used tools displaying this behavior?
msg118432 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-10-12 16:46
I doubt it.  As Senthil says, file invoking ftp it is a bug.  I'm just betting that *someone* is going to complain when it stops working in their particular situation.
msg118433 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-10-12 16:47
Ah, I thought this was not a bug, because of “RFC 1738, says that host, if present should be the FQDN of the machine”.  If it’s a bug I’m all for fixing it in all three versions.
msg118440 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-10-12 17:17
I'd say disable hostnames in file:// URIs altogether. There's no practical reason for forcing a hostname in there, and trying to check that it matches the local host's FQDN sounds like a distraction.
msg118441 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-10-12 17:17
(by disable I meant disallow, sorry)
msg118442 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-10-12 17:23
Éric: Well....I suppose that depends on how you look at it.

The RFC says that 'file:' does not specify a network protocol, and so "it's utility in network protocols between hosts is limited".  So, technically an implementation that decides to handle 'file://<fqdn>' by using ftp isn't *wrong*, but it certainly isn't something that someone writing a 'file:' uri should expect to work.

I agree with Senthil, I am -1 on backporting this to earlier versions because of the potential for breaking "working" applications (even though those applications shouldn't really be working :)

Antoine: except that the RFC allows FQDNs in 'file:' URIs.  So I don't think we can just reject them.
msg118446 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-10-12 17:42
With this explanation, I agree with Senthil’s plan too.
msg118447 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-10-12 17:47
I think the error message should be changed from 'allowed' to 'supported', though.
msg118652 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2010-10-14 11:58
Thanks for the comments and feedback.
Fixed this in revision 85475.
History
Date User Action Args
2010-10-14 11:58:20orsenthilsetstatus: open -> closed
resolution: fixed
messages: + msg118652

stage: patch review -> resolved
2010-10-12 17:47:28r.david.murraysetmessages: + msg118447
2010-10-12 17:42:01eric.araujosetmessages: + msg118446
2010-10-12 17:23:22r.david.murraysetmessages: + msg118442
2010-10-12 17:17:32pitrousetmessages: + msg118441
2010-10-12 17:17:18pitrousetnosy: + pitrou
messages: + msg118440
2010-10-12 16:47:36eric.araujosetmessages: + msg118433
2010-10-12 16:46:32r.david.murraysetmessages: + msg118432
2010-10-12 16:40:58eric.araujosetnosy: + eric.araujo
messages: + msg118431
2010-10-11 14:17:24r.david.murraysetmessages: + msg118361
2010-10-11 06:32:25orsenthilsetmessages: + msg118347
2010-10-10 15:49:39r.david.murraysetnosy: + r.david.murray
messages: + msg118335
2010-10-10 09:40:20orsenthilcreate