This goes together with removing database storage of stylesheets and templates (viewtopic.php?f=84&t=33456) but it is an entirely standalone piece of functionality.
Some work was done on this earlier and needs to be salvaged:
https://github.com/phpbb/phpbb3/tree/fe ... xperiment/
https://github.com/phpbb/phpbb3/commit/ ... eb157723aa
https://github.com/phpbb/phpbb3/commit/ ... 71485e5eae
https://github.com/phpbb/phpbb3/commit/ ... 935e06be76
Proper description of this RFC also needs to be written.
[RFC] SFTP support
- bantu
- 3.0 Release Manager
- Posts: 557
- Joined: Thu Sep 07, 2006 11:22 am
- Location: Karlsruhe, Germany
- Contact:
Re: [RFC] SFTP support
We should consider using a crypto library.
There is a PHP5 port of TerraFrost's phpseclib which is where the experimental phpBB code is also from: https://github.com/timmartin/phpseclib
There is a PHP5 port of TerraFrost's phpseclib which is where the experimental phpBB code is also from: https://github.com/timmartin/phpseclib
Re: [RFC] SFTP support
(S)FTP access looks like an ugly work around. Why can't file permissions be set properly?
Re: [RFC] SFTP support
Proper file permissions do not allow the webserver to write to the files it executes.
Re: [RFC] SFTP support
Why not?naderman wrote:Proper file permissions do not allow the webserver to write to the files it executes.
Re: [RFC] SFTP support
Because then if you have a code execution hole in your application an attacker can overwrite your files, therefore they will be able to potentially serve their own pages to your site's users. An application which never executes code it has write access to will not permit an attacker to affect anyone but themselves.
In context of database-driven web applications, attackers who are able to run arbitrary code can frequently write appropriate code into the database such that users get payload in their markup anyway.
Where write protection is still effective is cross-application compromise (application X overwriting application Y's files). Generic exploits do not try to figure out what databases they might have access to via other applications, but they do try to write all files on the filesystem they can find.
In context of database-driven web applications, attackers who are able to run arbitrary code can frequently write appropriate code into the database such that users get payload in their markup anyway.
Where write protection is still effective is cross-application compromise (application X overwriting application Y's files). Generic exploits do not try to figure out what databases they might have access to via other applications, but they do try to write all files on the filesystem they can find.
Re: [RFC] SFTP support
Ah, like that. I read naderman's statement the wrong way.
Anyway, wouldn't SFTP support effectively give the webserver permission to write to the files it executes?
Anyway, wouldn't SFTP support effectively give the webserver permission to write to the files it executes?
Re: [RFC] SFTP support
If we don't store the password, not outside a single request. Even if we do store the password, other software on the same server won't be able to write to phpbb's tree (unless of course it retrieved password from the database).
The other reason to do SFTP is users whose hosting provider does not allow webserver to write to php tree (although I imagine this is a very small subset). For these users, and anyone else who uses FTP, SFTP would be preferable to FTP that we currently provide.
Moved to 3.2 for now.
The other reason to do SFTP is users whose hosting provider does not allow webserver to write to php tree (although I imagine this is a very small subset). For these users, and anyone else who uses FTP, SFTP would be preferable to FTP that we currently provide.
Moved to 3.2 for now.