I'm running into an issue right now where 'drush dl' won't work because my user doesn't have permissions to write to to the modules directory, and I can't seem to find a way around it without su-ing to root since running drush with sudo still runs the cvs command as the user running the script.

One way I've got around this in my own scripts is to check if the user is either 'root' or the owner of the files (in my case 'www-data'), and if not, run all the commands with sudo -u.

For example:

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d views -r DRUPAL-6--2-5 contributions/modules/views

Turns into:

sudo -u www-data cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d views -r DRUPAL-6--2-5 contributions/modules/views

If the user running the script needs to use sudo, drush can prompt for the sudo password and then all the 'sudo -u' commands should work fine. I realize this isn't a problem for everyone, but it could save a lot of confusion since without the verbose flag, this is the current error you get:

Unable to checkout views from cvs.drupal.org.
Unable to check out  to /var/www/webroot/ from cvs.drupal.org
An error occurred at function : pm_dl

Which doesn't really describe the real problem.

So yeah, it would be very nice if drush did this!

Comments

gnat’s picture

gnat commented

As far as I understand *nix permissions models this is not only impossible, but also not a good idea. On many systems, including Debian and Ubuntu which I am the most familiar with, the command line interface to PHP is a separate package from the PHP that interacts with Apache. For this reason, PHP processes when invoked from the web, are run by the system user for Apache (www-data on Debian/Ubuntu systems), and the logged in system user when invoked from the command line. In order to change that reality you need to change to a different system user (ie: www-data) to run the script. This will require root level permissions on most systems anyway, gaining nothing.

Also, all systems are not Debian, and not even all Debian systems work this way. I run suPHP on a server, which doesn't allow scripts owned by root or www-data to run. Many people are on shared BSD hosts that run their web sites as well as CLI PHP as their system user. Drush has to work across this wide range of systems and configurations which we cannot know ahead of time.

I think what we really need is documentation describing a safe and standard Unix work around that any sys admin can follow. Essentially it breaks down to two steps.

  1. Change the group of the "sites/all" or "sites/sitename" directory to some group that all desired system users are in. For this example, its just the group of my user "nat". This command is being run from your Drupal root directory: 
    $ sudo chgrp -R nat sites/all

    This will recursively change the group of all files to "nat"

  2. Make sure that this group has the rights to write as well as execute code within these directories. (Execute is needed for creating new directories). To give these rights recursively run something like: 
    $ sudo chmod -R g+wx sites/all

    Again, this is run from the Drupal root directory. Also it is likely more secure to only apply this permission to the "modules" or "themes" directories of any site.

I will let the actual maintainers weight in on this, but that's my $0.02.

adrian’s picture

adrian commented

you need to add the user you are running the script as into the www-data (or apache, or nobody on some systems) group, and then do the chgrp and chmod commands as specified

Also. the group should only have write access to your sites/$surl/files directory.

anarcat’s picture

anarcat commented
Title: run commands as web server » run commands as the web server user
Status: Active » Closed (won't fix)

In my opinion, this is outside the scope of Drush: your permissions should be setup properly so that the user running drush can write to it. I see very little use of privilege separation within drush itself, apart from requiring some things to be ran as root, such as restarting the web server, in our case, but that's dealt with using a drush_exec().

donquixote’s picture

donquixote commented

I think the real problem is this one:
#841310: How to change permissions and owner after dl / update?

jmlane’s picture

jmlane commented
Component: Code » PM (dl, en, up ...)

From the perspective of a brand new Drush user, the documentation should explain what the required Drupal file permissions should be in order to get Drush to work out of the box. Either give a recommendation on how to configure the file permissions or point to a handbook article that explains the Drupal best-practice, with a statement of how Drush fits into the model explained in the linked article.

I realize that some people will have their own privilege scheme, will have the system administration experience to know how to secure their Drupal files hierarchy, and allow Drush to work without special permissions, but this is not something that should be taken for granted as common knowledge to all Drush users.