[development] Sympal script / module Fetcher as profile enhancement
David Metzler
metzlerd at metzlerd.com
Tue Mar 27 15:53:55 UTC 2007
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 at 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
More information about the development
mailing list