search

4udak / pyftpdlib

Automatically exported from code.google.com/p/pyftpdlib
Other
1 stars 1 forks source link

Empty password problem with default server #241

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Download pyftpdlib
2. python -m pyftpdlib.__init__ 

What is the expected output? What do you see instead?
220 pyftpdlib 1.0.1 ready.
USER anonymous
331 Username ok, send password.
PASS 
501 Syntax error: command needs an argument.
QUIT
221 Goodbye.

Please use labels and text to provide additional information.
I don't know if RFCs say that empty passwords should be accepted or not, but it 
is clearly an inconvenience.

Original issue reported on code.google.com by techtonik@gmail.com on 8 Mar 2013 at 11:25

GoogleCodeExporter commented 9 years ago 
See also - http://curl.haxx.se/mail/lib-2011-02/0321.html - might be the trace 
of the same bug.

Original comment by techtonik@gmail.com on 8 Mar 2013 at 11:25

GoogleCodeExporter commented 9 years ago 
No, AFAIK empty passwords are not allowed in FTP.
I don't recall any RFC talking about this, specifically because "PASS" is a 
command which requires an argument.

Original comment by g.rodola on 8 Mar 2013 at 11:37

GoogleCodeExporter commented 9 years ago 
Can you find a reference? I'd like to read about that, but the term PASS is too 
generic. How to specify an empty PASS then? For some reason it seems that other 
FTP servers allow empty passwords for anonymouses.

Original comment by techtonik@gmail.com on 8 Mar 2013 at 1:20

GoogleCodeExporter commented 9 years ago 
Quickly searching for "ftp empty password" doesn't seem to bring up any useful 
result. 
What other FTP servers allow empty passwords for anonymous?
Why do you think it's important?

Original comment by g.rodola on 11 Mar 2013 at 12:07

GoogleCodeExporter commented 9 years ago 
Because my file manager fails with pyftpdlib server and I never had problems to 
login into other anonymous services with it. I guess that curl may also have 
the same behavior (as a client) and therefore all scripting languages that use 
it will fail as well.

It is important to provide a seamless user experience. It is also an intuitive 
way to behave - provide an empty password for anonymous.

In fact - if you examine the text I posted, the word 'PASS ' has a space after 
it and 'QUIT' doesn't, which means that PASS command has an empty argument, but 
pyftpdlib is unable to see it.

Original comment by techtonik@gmail.com on 11 Mar 2013 at 1:37

GoogleCodeExporter commented 9 years ago 
I haven't been affected by this myself, but I just tried searching for "ftp 
null password" and found https://bugzilla.mozilla.org/show_bug.cgi?id=32761 
which looks like it might provide some insight? (and links to various RFCs)

Original comment by gc...@loowis.durge.org on 11 Mar 2013 at 2:08

GoogleCodeExporter commented 9 years ago 
ProFTPD I believe will accept an empty argument, or at least a "newline" as the 
argument without checking it, and I think IIS does as well.  I believe it's 
fairly common to allow an empty or whitespace-only password by sending just a 
blank line.

Original comment by jlo...@gmail.com on 11 Mar 2013 at 2:12

GoogleCodeExporter commented 9 years ago 
Ok agreed, it appears reasonable.
Thanks for your insights.

Original comment by g.rodola on 11 Mar 2013 at 3:00

GoogleCodeExporter commented 9 years ago 
Fixed in r1195.
Also, I confirm proftpd allows empty passwords (aka "PASS without an argument") 
for all users (not only anonymous).
Therefore "PASS " and "PASS" are the same.

Original comment by g.rodola on 11 Mar 2013 at 8:21

GoogleCodeExporter commented 9 years ago 
What is the process to record that into RFC?

Original comment by techtonik@gmail.com on 12 Mar 2013 at 8:25

GoogleCodeExporter commented 9 years ago 
What do you mean?

Original comment by g.rodola on 12 Mar 2013 at 8:32

GoogleCodeExporter commented 9 years ago 
I mean that if that verbose FTP RFC doesn't contain guidelines how to threat 
empty passwords, it needs to be added into it.

Original comment by techtonik@gmail.com on 12 Mar 2013 at 8:36

GoogleCodeExporter commented 9 years ago 
I'm not sure. I doubt that very old RFCs (e.g. 959) can be edited nowadays. 
Instead, if such a thing should be added, I *suppose* they get superseded by 
newer ones. Anyway, I wouldn't know where to submit such a request.

Original comment by g.rodola on 12 Mar 2013 at 8:42

GoogleCodeExporter commented 9 years ago 
I bet only Google and Microsoft know where to submit these. That why RFC suxx 
today.

Original comment by techtonik@gmail.com on 12 Mar 2013 at 9:33

GoogleCodeExporter commented 9 years ago 
It doesn't take much searching to find...
http://www.rfc-editor.org/indsubs.html

Original comment by gc...@loowis.durge.org on 12 Mar 2013 at 12:13

GoogleCodeExporter commented 9 years ago 
This bureaucracy is for submitting whole documents. Not for the fixes to 
existing ones.

Original comment by techtonik@gmail.com on 12 Mar 2013 at 1:42

GoogleCodeExporter commented 9 years ago 
...and there's a process for that too. I guess you didn't even bother looking 
at the FAQ? *sigh*
http://www.rfc-editor.org/rfcfaq.html#errata

I won't bother making any more comments on this bug, as it's getting slightly 
off-topic for pyftpdlib.

Original comment by gc...@loowis.durge.org on 12 Mar 2013 at 2:22

GoogleCodeExporter commented 9 years ago 
It is not offtopic, because the cause of this bug is missing RFC information. 
The link that you've posted doesn't help, because there is no error in the RFC 
- it just doesn't include this scenario.

Original comment by techtonik@gmail.com on 12 Mar 2013 at 2:42

GoogleCodeExporter commented 9 years ago 
I don't think there's any issue with the RFC, this is an implementation detail. 
The RFC under the USER command just says "Additional identification information 
in the form of a password and/or an account command may also be required by 
some servers." 

The PASSword command description doesn't place any requirements on length or 
format, so passing an empty string followed by CRLF wouldn't be against the RFC 
as far as I can tell. It'd be up to the FTP server process whether or not to 
allow blank passwords or not (hence "*may* also be required").  In this case, 
pyftpdlib is just choosing to implement this the same way other common FTP 
servers have, by allowing a blank PASS command argument provided the user 
account has no password set.

Original comment by jlo...@gmail.com on 12 Mar 2013 at 2:58

GoogleCodeExporter commented 9 years ago 
Indeed. I think Jay is right.

Original comment by g.rodola on 12 Mar 2013 at 3:02

GoogleCodeExporter commented 9 years ago 
Right, and the user expectation is that all FTP servers allow empty passwords 
for anonymous users. It is worthy to be recorded into RFC, but starting and 
sending the next draft of current RFC is not what I can currently do.

Original comment by techtonik@gmail.com on 12 Mar 2013 at 3:03

GoogleCodeExporter commented 9 years ago 
That's certainly not the way it's always been though. I remember when I first 
started using the internet (mid 90s) the recommendation when logging into an 
anonymous FTP server was to use your email address as the password. (before 
spam had been invented, obviously!)

And without wishing to send this discussion off-topic again, I believe RFCs 
concern themselves more with technical requirements, rather than "user 
expectations".

Original comment by gc...@loowis.durge.org on 12 Mar 2013 at 3:15

GoogleCodeExporter commented 9 years ago 
Technical requirements are born from the user needs. Too bad that original user 
stories are lost as a result. I remember these email requirements too.

Original comment by techtonik@gmail.com on 12 Mar 2013 at 4:45

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 9 Apr 2013 at 2:47

GoogleCodeExporter commented 9 years ago

Original comment by g.rodola on 9 Apr 2013 at 4:29