Chx: Upon reading http://www.webschuur.com/publications/blogs/2007-01-16-stor_of_a_drupal_... I find that it'd be just great to borrow these from Joomla.

Bèr: FWIW, and for those who prefer to be aawwed and aaahd, rather then read through my blogs, I attached a screenshot of the FTP configuration.
More on FTP configuration can be found here: http://dev.joomla.org/content/view/2013/93/
What is this FTP filesystem anyway?
The previous version of Joomla, the 1.0.X series had issues with ownership of files on a server. It's a little bit technical, to give you an idea, its possible for files on an Apache web server to be owned by a user called "nobody". Go figure. Anyway, there would be conflicts with who owned files, whether it was the FTP account or Apache itself. This would lead to permission problems when Joomla would try to upload files.
The solution in 1.5 is for Joomla to actually use an FTP account for everything, and then there are no conflicts.
If that was all a little confusing to you, just create an FTP account for Joomla to use and enter the details in this screen.

This issue is moved from #110116 because of broken HTML. Also splitting that issue up into two: this one is to deal with the FTP layer.

CommentFileSizeAuthor
joomla_ftp_0.png92.19 KBBèr Kessels

Comments

Bèr Kessels’s picture

Bèr Kessels commented

The correct URL is http://webschuur.com/publications/blogs/2007-01-16-stor_of_a_drupal_bele...

dries’s picture

dries commented

I like the FTP idea.

(It also got me thinking. Could we use CVS instead of FTP. CVS doesn't give the security FTP provides, but it does has the advantage of being able to merge in local changes. The CVS idea is likely to be a dead-end but I figured mention it nonetheless. Maybe some of you have additional insights. :))

Bèr Kessels’s picture

Bèr Kessels commented

I am not sure how cvs could do this. The FPT method is primary push, and AFAIKS that is not something svn or CVS is capable of.

We all agree that allowing this
[Running Drupal App] =write=> [Drupal Codebase]
is insecure. Joomla! has this:
[Running Joomla! App] => [Joomla buit in FTP client] => [teh intarweb (or localhost)] => [FTP server] =write=> [Joomla Codebase]
Which makes it effectively so that Joomla never needs write access in its own codebase.
With CVS afaiks you can only do:
[Running Drupal App] =request=> [CVS client] =checkout/write=> [Drupal Codebase]
Which still forces you to give CVS client write access. 'request' would probably be nothing more then either exec()-ing the CVS client, or running a PHP-based CVS client. The only way this is more secure then the first option, is when you run the CVS client with setuid. Normally the one running the CVS client is the one who needs the file write permissions too.
However, if CVS is capable of the following:
[Running Drupal App] => [CVS client] =commit=> [teh intarweb (or localhost)] => [CVS server] =write=> [Drupal Codebase]
It wold be a great idea.

chx’s picture

chx commented
Assigned: Unassigned » chx

ber, nice workflows. Yes, CVS could do that but would require a post commit hook (actually this is what NowPublic does on its devel servers, dev guys commit their stuff into repo, and it pushes to stuff into htdocs so we can test). Horribly complicated. Adn the regular shared hosting guy here won't have CVS on his server. Not even command line to exec it...

There are many ways to do this:

  1. raw socket client. Not for core, thanks.
  2. FTP extension. Rare as hen's teeth, I believe.
  3. cURL extension. Much better and more commonplace.
  4. FTP wrapper.

I will code using the FTP wrapper and probably provide a cURL variant as well because the PHP4 FTP wrapper is seriously limited. Yes, shared hosters might not allow either, but I assure you that those who think they are more secure because of this won't allow raw sockets or FTP extension either.

bradlis7’s picture

bradlis7 commented

I think having ftp would be good not only in the installer, but in upload.module, and other tasks as well. I'd even

I just had it happen tonight that drupal made a folder (files/tmp), and I could not delete it to move an older folder back in it's place... very frustrating. Anyways, this sounds good.

mwtest2’s picture

mwtest2 commented

subscribe

Chris Johnson’s picture

Chris Johnson commented

I'm all in favor of making life easier for those who install or upgrade Drupal on a wide variety of hosting arrangements. So this is not a -1 on this issue.

That said, let me point out that FTP and security in the same sentence is an oxymoron. FTP is no more secure than using Telnet -- and nobody here would use Telnet, would they? We all use SSH, right? ;-)

sime’s picture

sime
any/any
Location Melbourne
commented

I use SFTP and I usually find it's available on any cpanel setup I encounter. So is the topic of security over ftp simply a question of "best practices"?

chx’s picture

chx commented

Let's not forget tha the server does an FTP back to itself, so basically you need to eavesdrop on the loopback interface...

Steven’s picture

Steven commented

Regarding security: you should be more worried about sending your normal Drupal username and password in the clear. With PHP code access, anyone can pwn your server.

If you want to avoid this, we could use SSH, even during the installation process. However, this is a different issue.

Bèr Kessels’s picture

Bèr Kessels commented

A choice
(x) FTP (insecure, find out more »)
(x) sFTP

should do, the protocol and/or libs hardly differ, so it won't take a lot of code or logic to have both sFTP and FTP as option.

grendzy’s picture

grendzy commented
Status: Active » Closed (duplicate)

Active issues here: #536630: [Meta issue] Plugin manager for D7 code freeze spec