Sympal script / module Fetcher as profile enhancement
Hello, What about using the sympal script moduleFetcher in profile.module in order to be able to add dynamically new contributed module in the installation process ? http://drupal.org/project/sympal_scripts The moduleFectcher is able to catch module from the official Drupal web site and install it into the directory tree. There is several issues I know about security around such a process and I am agree from it. In a other hand, a profile module that could be able to install contributed module automatically and perform standard settings for it, it could be fun too ! So please tell me more about such a feature. I am ready to help you to reach critical issues around it. -- Cordialement, Jean-Marie Renouard
Op dinsdag 27 maart 2007 10:02, schreef Jean-Marie Renouard:
The moduleFectcher is able to catch module from the official Drupal web site and install it into the directory tree.
There is several issues I know about security around such a process and I am agree from it.
The solution for the biggest secutity issue, in this system, is that you don't have to rnu it from the web. The security issue is: If your web-application can write (to) itself, you have a severe security hole. Hence: If your website can install and run modules and code itself you have a problem. sympal scripts is ran from the CLI. And no! That does not mean "but but but Joe User Does Not Know the CLI".:) It is meant to be fired from scripts that are ran from secure applications (on the web). Such as webmin, plesk, or your dedicated System-Admin-Drupal-Installation, running off a separare webserver. The way I use it, is trough a script that I run from my desktop. It allows me to install modules w/o spending any time on the servers CLI. We still have plans to merge this into webmin, but until now it generally works fine enough. Bèr
Hi Bér, I don't know why we can find a positive issue to this point. :) We could have write permissions during the installation process and at the end of the process a instruction such as permission restrictions to read only on the module file. I hope we can find a positive issue to this. In fact, I find this is a great feature to be able to install contributed modules at the installation time. Even if this the module directory have write permissions, there is many other part such databases, cache directory that have write permissions. What can we do to avoid or "work around' such problem ? I find this is a great and wonderful feature in fact ! Can we find a other way such "unsafe module directory" system or other ways like this ? This is because I don't know this is impossible that we can reach it :) Jean-Marie On 3/27/07, Bèr Kessels <ber@webschuur.com> wrote:
Op dinsdag 27 maart 2007 10:02, schreef Jean-Marie Renouard:
The moduleFectcher is able to catch module from the official Drupal web site and install it into the directory tree.
There is several issues I know about security around such a process and I am agree from it.
The solution for the biggest secutity issue, in this system, is that you don't have to rnu it from the web.
The security issue is: If your web-application can write (to) itself, you have a severe security hole. Hence: If your website can install and run modules and code itself you have a problem.
sympal scripts is ran from the CLI.
And no! That does not mean "but but but Joe User Does Not Know the CLI".:) It is meant to be fired from scripts that are ran from secure applications (on the web). Such as webmin, plesk, or your dedicated System-Admin-Drupal-Installation, running off a separare webserver.
The way I use it, is trough a script that I run from my desktop. It allows me to install modules w/o spending any time on the servers CLI. We still have plans to merge this into webmin, but until now it generally works fine enough.
Bèr
-- Cordialement, Jean-Marie Renouard
Seems we've been hashing this one around for a while and it only leads to a stalemate. I was thinking about this and wondering about potential radically different approaches. What if we were to model the software update process based on what many OS's do. * the module downloads updates into a staging directory (perhaps still in tgz format). .info files could be used as module signatures to go with the tarballs so that the directory that this stuff gets downloaded into doesn't have to be able to execute code. You could cron_hook this so that updates would be already downloaded when you installed it. * the normal drupal UI is modified to look for .info files and corresponding tar files and ask the users if they want to install. * when the user approves the updates, a privileged cron script performs the updates at the next scheduled time. This script could also be run manually, but the idea would be that if you ever invoked it via drupal, you'd have to specify credentials. This is of course a very rough idea, but I'm hoping it might get some creative juices flowing on a way to solve the problem that doesn't make us uncomfortable about the security ramifications. On Mar 27, 2007, at 5:55 AM, Jean-Marie Renouard wrote:
Hi Bér,
I don't know why we can find a positive issue to this point. :)
We could have write permissions during the installation process and at the end of the process a instruction such as permission restrictions to read only on the module file.
I hope we can find a positive issue to this. In fact, I find this is a great feature to be able to install contributed modules at the installation time.
Even if this the module directory have write permissions, there is many other part such databases, cache directory that have write permissions.
What can we do to avoid or "work around' such problem ?
I find this is a great and wonderful feature in fact ! Can we find a other way such "unsafe module directory" system or other ways like this ?
This is because I don't know this is impossible that we can reach it :)
Jean-Marie
On 3/27/07, Bèr Kessels <ber@webschuur.com> wrote:
Op dinsdag 27 maart 2007 10:02, schreef Jean-Marie Renouard:
The moduleFectcher is able to catch module from the official Drupal web site and install it into the directory tree.
There is several issues I know about security around such a process and I am agree from it.
The solution for the biggest secutity issue, in this system, is that you don't have to rnu it from the web.
The security issue is: If your web-application can write (to) itself, you have a severe security hole. Hence: If your website can install and run modules and code itself you have a problem.
sympal scripts is ran from the CLI.
And no! That does not mean "but but but Joe User Does Not Know the CLI".:) It is meant to be fired from scripts that are ran from secure applications (on the web). Such as webmin, plesk, or your dedicated System-Admin-Drupal-Installation, running off a separare webserver.
The way I use it, is trough a script that I run from my desktop. It allows me to install modules w/o spending any time on the servers CLI. We still have plans to merge this into webmin, but until now it generally works fine enough.
Bèr
-- Cordialement, Jean-Marie Renouard
* when the user approves the updates, a privileged cron script performs the updates at the next scheduled time. This script could also be run manually, but the idea would be that if you ever invoked it via drupal, you'd have to specify credentials.
Hi, this is unacceptable, because most of the users running shared hosts don't have access to privileged cron scripts. I personally think that Drupal should not even run when any of the system directories (sites, modules, themes?) are system-wide writable. What about this approach? - Chmoding any of the system directories writable will take Drupal web offline (maintenance mod) immediately - Admin user is still able to log in to site, so he goes to administration, perform neccessary installations from the web and then put the web back online by settings modules/ directory not-writable. So the common practice will be: 1) chmod 777 modules (or ./scripts/start-install.sh) 2) log in to drupal administration (system is offline, but accessible to admin user) 3) perform installation 4) chmod 555 modules (or ./scripts/stop-install.sh) The question is: will this be easier to users than downloading modules directly? :) Jakub
Op dinsdag 27 maart 2007 18:48, schreef Jakub Suchy:
* when the user approves the updates, a privileged cron script performs the updates at the next scheduled time. This script could also be run manually, but the idea would be that if you ever invoked it via drupal, you'd have to specify credentials.
Hi, this is unacceptable, because most of the users running shared hosts don't have access to privileged cron scripts.
I personally think that Drupal should not even run when any of the system directories (sites, modules, themes?) are system-wide writable. What about this approach?
There is another way, and AFAIK Karoly (aka chx) already did some work for it. Stolen from how Joomla! does it: http://webschuur.com/publications/blogs/2007-01-16-stor_of_a_drupal_beleiver... is the idea explained http://drupal.org/node/110141 is the issue for it.
This adds system load to every single page for little benefit. The check could just as well be done on a scheduled basis (cron jobs) ----- Original Message ----- From: "Jakub Suchy" <jakub@rtfm.cz> To: <development@drupal.org> Sent: Tuesday, March 27, 2007 6:48 PM Subject: Re: [development] Sympal script / module Fetcher as profileenhancement [...]
What about this approach?
- Chmoding any of the system directories writable will take Drupal web offline (maintenance mod) immediately [...]
On Mar 27, 2007, at 9:48 AM, Jakub Suchy wrote:
* when the user approves the updates, a privileged cron script performs the updates at the next scheduled time. This script could also be run manually, but the idea would be that if you ever invoked it via drupal, you'd have to specify credentials.
Hi, this is unacceptable, because most of the users running shared hosts don't have access to privileged cron scripts.
Is this statement still true if you think of a "priviliged cron script" as simply one that isn't run by apache and therefor has write access to the drupal directories? I wasn't talking about root here. My provider certainly allows this. The FTP approach also has possibilites, but I'm not sure how well it would work given our packaging systems. I'd love to figure out how drupal can have a hook that "prompts for credentials" and then runs a process as a different user. I'll continue to be trying to figure out a way to make this work... Dave
On 3/27/07, David Metzler <metzlerd@metzlerd.com> wrote:
Seems we've been hashing this one around for a while and it only leads to a stalemate. I was thinking about this and wondering about potential radically different approaches.
What if we were to model the software update process based on what many OS's do.
There are two pieces here. One is install profiles, which we'll bundle with scripts on Drupal.org directly and have complete tarballs. The other is updates, which this is more related to, and for which upgradestatus should be looked at. -- Boris Mann Skype borismann http://www.bryght.com
On 3/27/07, Boris Mann <boris@bryght.com> wrote:
The other is updates, which this is more related to, and for which upgradestatus should be looked at.
Boris means the update_status module ( http://drupal.org/project/update_status)* *, which monitors for new releases on drupal.org. It does not install updates yet. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
participants (7)
-
Boris Mann -
Bèr Kessels -
David Metzler -
FGM -
Jakub Suchy -
Jean-Marie Renouard -
Khalid Baheyeldin