By Mtt-2 on

Hi,

I know these issue may seem sensitive and it has been discussed before on Drupal forum but I've never found answsers to some questions I ask myself (as a rather tech newbie) :

I work on a Mac os x and I daily use a small app call Things to manage my todolist. I have an admin account, not a root one.
10 minuts ago Things warned me that a new version is available and asked me to click a button to download and install the new version.
I did it.
And Things handled all the stuff for me and relaunch nicely to run the last version of himself.

I also work on a webserver (some sort of a remote desktop) and I daily use a small app call Drupal to manage content and community of users.
I have an admin account and not a root one.
Drupal also warned me about a new version but I am not offered an automatic upgrade as on my desktop.

So mo question is why is it evil to run an automatic upgrade on server and not on desktop ?

Am I then a fool to allow Things to upgrade automatically ? Should i download/unpack on my desktop as I do on my webserver ?

Both example seems identical to me. Both environment are critical but for the desktop autoupgrade is cool and widely use but for webserver this is not the case.

I surely miss something and I would be grateful if some kind of tech wise personn just explain me briefly.

Thanks
Matt

Comments

nevets’s picture

nevets commented

One big difference is with your Drupal example, the account that matters is not the Drupal one but the OS account Drupal is running on. For security you do not want most files writable as it opens a large security whole. This means Drupal is not in a position to overwrite it's own files (which is a good thing).

Mtt-2’s picture

Mtt-2 commented

I understand what you say so I can conclude that it is also the same vulnerability to let a desktop app upgrade automatically (one can insert malicious code to delete all app's files or maybe more files on desktop)
I mean that my desktop app's core developer may goes completely insane and decides to ship an upgrade that will delete all files on my computer.
Because this desktop app runs with my admin account.
So this is a huge vulnerability on my desktop. Such as the one on my webserver if I allow Drupal to auto-upgrade itself.

thanks.

cog.rusty’s picture

cog.rusty commented

Your desktop application has been designed to work on your OS, is aware of your OS, and has been installed with certain privileges. Drupal is designed for the web and you will often see instructions like "make your uploads directory writable by the web server, in whichever way this is done in your OS".

Also, unlike your application, Drupal is designed to be exposed to the web.

That doesn't mean that things can't improve a lot, but there is a difference.

styro’s picture

styro commented

I work on a Mac os x ... I have an admin account, not a root one.

Just a clarifying note on the unix underpinnings of your Mac - because your account is an admin one, it can become root for certain tasks (like using sudo on a Linux machine). Be aware that when your OS asks you for your password to do something that task IS run as root. In this case the account that 'owns' and can write to the app files (ie root) is different to the one that runs it (ie your account), and your app needs to run as root to update itself.

Or if it doesn't ask for your password, your app is probably installed somewhere non system related that your user account has full permissions (eg your home directory). And anything installed here by your user account can't overwrite any system files. In this case the account that owns the app files is the same as the one that runs it, but it is only your own personal files that are at risk and not the system files.

Note that automatic upgrades still have (admittedly very remote) risks - eg if someone has attacked the DNS servers you use, or the website your application talks to, you could end up downloading and running anything without realising it. But in general, that risk isn't worth worrying about too much.

With a web application on a server it is usually* desirable that the operating system account that 'owns' and has write access to the apps files (eg your FTP account) is a different account than the one that actually runs it (the webserver). That way if the web app has a vulnerability and is tricked into doing something it shouldn't by an attacker, the webserver can't overwrite the application files (it can probably still do other stuff though).

* Another note: if your webserver uses suexec to make the app run with the same account as the owner of the files, then you gain extra protection from other users/sites on the server at the expense of some protection from users out on the web. It's a bit of a "swings and roundabouts" situation depending on who you want the most protection from, and the best security comes from using different accounts on a server that has no other users on it (eg a dedicated or a virtual server).

So in general, a hypothetical automatic upgrade for Drupal would require lax security if it were to be run by the web server account. I think the approaches taken by people working on this are looking at ways of using your FTP account for this. And this approach is a harder problem to solve on a shared webhost securely than just using a sudo like mechanism built into your desktop.

Does that make more sense now?

--
Anton

Mtt-2’s picture

Mtt-2 commented

I think I am definitively done with my questions and this is a lot more clear in my mind .. Hat down for your write up fellows.

I kept thinking the whole day about that auto-upgrade question. Thinking strictly logically one could say that auto-upgrade should not be necessary for Drupal. I mean even if such functionnality was up and running it could'nt be that easy to upgrade a, let's say, newspaper website. You have to block all writing to database, unplugged all modules and so on and so on.. you *have* to run through some time consuming steps that couldn't be automated. Then, unpacking and uploading Drupal core files should not be a real difference in your day to day maintenance work (at least if you are not some sort of a crazy web manager that upgrade its CMS on production server)

Thanks again

Matt

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

The Plugin Manager exists and will do as much of this as is possible/reasonable.

It is a secure tool in that it uses FTP/SSH to write the files instead of the Apache permissions directly.

--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book

--
Morris Animal Foundation

dellintosh’s picture

dellintosh commented

In addition to the great information shared by others, I want to share a new process I've recently started using, and found to be very helpful for exactly this. It's called Aegir (http://groups.drupal.org/aegir-hosting-system), and I've been using this to handle my core updates on several client sites. So far it handles backup, migrate, and updating of the Drupal core.

There is a video which outlines the install process, and I'd encourage anyone concerned about security to watch that for suggested best practices. Aegir runs as its own user, who has limited permissions.. more info in the video though.

Thanks, and I hope that helps!
-dellintosh