Wrong directory permissions
| Project: | Drupal.org infrastructure |
| Component: | Packaging |
| Category: | bug report |
| Priority: | critical |
| Assigned: | dww |
| Status: | patch (code needs work) |
I found some difference with directory permissions in drupal bundles:
[u50477@be53 ~/tmp]$ ls -l drupal-5.1 | egrep "^d"
drwx------ 2 u50477 www 1024 Jan 30 03:20 includes
drwx------ 3 u50477 www 1536 Jan 30 03:20 misc
drwx------ 31 u50477 www 512 Jan 30 03:20 modules
drwx------ 3 u50477 www 512 Jan 30 03:20 profiles
drwx------ 2 u50477 www 512 Jan 30 03:20 scripts
drwx------ 4 u50477 www 512 Jan 30 03:20 sites
drwx------ 7 u50477 www 512 Jan 30 03:20 themes
[u50477@be53 ~/tmp]$ ls -l drupal-5.0 | egrep "^d"
drwxr-xr-x 2 u50477 www 1024 Jan 15 15:20 includes
drwxr-xr-x 3 u50477 www 1536 Jan 15 15:20 misc
drwxr-xr-x 31 u50477 www 512 Jan 15 15:20 modules
drwxr-xr-x 3 u50477 www 512 Jan 15 15:20 profiles
drwxr-xr-x 2 u50477 www 512 Jan 15 15:20 scripts
drwxr-xr-x 4 u50477 www 512 Jan 15 15:20 sites
drwxr-xr-x 7 u50477 www 512 Jan 15 15:20 themes
So, you can see directories in drupal-5.1 has wrong permissions. Thus you will get these error message:
[Tue Feb 6 14:35:43 2007] [error] PHP Warning: require_once(./includes/bootstrap.inc) [function.require-once]: failed to open stream: Permission denied in /home/www/index.php on line 12
[Tue Feb 6 14:35:43 2007] [error] PHP Fatal error: require_once() [function.require]: Failed opening required './includes/bootstrap.inc' (include_path='.:') in /home/www/index.php on line 12
#1
same for me (on freebsd).
i solved it by running
find . -type d -exec chmod 755 {} \;
in the drupal directory
#2
Check out the archive before you extract using:
$ tar tzvf drupal-5.1.tar.gz | moreyou see in the archive file permissions like:
drwxr-sr-x drupal-cron/drupal-cron 0 2007-01-29 19:20:06 drupal-5.1/modules/color/
drwxr-sr-x drupal-cron/drupal-cron 0 2007-01-29 19:20:06 drupal-5.1/modules/color/images/
as opposed to:
drwxr-xr-x drupal-cron/drupal-cron 0 2007-01-15 07:20:02 drupal-5.0/modules/color/
drwxr-xr-x drupal-cron/drupal-cron 0 2007-01-15 07:20:02 drupal-5.0/modules/color/images/
Looks like the problem is still in CVS:
drwxr-sr-x drupal-cron/drupal-cron 0 2007-02-14 07:03:19 drupal-5.x-dev/modules/color/
drwxr-sr-x drupal-cron/drupal-cron 0 2007-02-14 07:03:19 drupal-5.x-dev/modules/color/images/
Is something is funky with the CVS server?!
Problem is also present in the 4.7.6 tarball:
drwxr-sr-x drupal-cron/drupal-cron 0 2007-01-29 16:55:02 drupal-4.7.6/modules/
#3
FYI, "man chmod" says that the "s" flag means:
s The set-user-ID-on-execution and set-group-ID-on-executionbits.
which doesn't even seem to be a valid flag for directories?
#4
все забили хуй на это.
#5
I agree :D
(subscribing)
#6
this is really a server/packaging issue.
#7
untested, but something like this is probably a good idea. we already chmod() the .info files before we try to open them for writing, so it seems natural to ensure sane permissions on all directories and files before we tar them up.
Also, perhaps we should change the ownership of the files as we package them with tar, so that everything is owned by 0/0 or something, instead of drupal-cron/drupal-cron...
#8
tested on d.o (not on the live packages) -- works exactly as intended. any final objections before i commit, install, and run a version of this to repackage everything? since it's not changing code, only file perms, i'm in favor of just fix all the existing tarballs...
#9
please fix them all - as long as there is a backup. The code looks ok, but I'm not too familiar with project module.
#10
Bah, I was about to commit this and unleash it when I realized this isn't going to work as-is. Some contribs (gee, like project.module and cvs.module(!)) ship CLI scripts that should be chmod 755, not 644. So, we have to be smarter than this. A few alternatives:
chmod '=rw,+X'Preferences?
#11
Drupal's core CLI scripts already ship as 644. Are the one you are referring to supposed to be run by the admin, or are they run by the module?
#12
I can't speak for all of contrib, but the CLI scripts in *my* modules are run either by hooks within CVS itself, or via cron (UNIX cron, as a priv'ed user, not httpd and cron.php). So yeah, an admin has to set them up and configure them appropriately. However, it's a little annoying if they also have to chmod them, I'd rather not have to document that step in the install instructions.
#13
probably better not to make a script executable if the developer didn't intend it to be (I can see some bad security mistakes happening that way).
So, if it's possible, #2 above seems best, and #1 is second best.
#14
Assuming this only is going to affect a copied tree of files that are about to be packaged, I don't have any comments. But if the recursive chown/chmod's were going to be run against CVS or the documentroot I wanted to make some comments:
A recursive chown to root:root is problematic because it would also break our security structure here on the OSL drupal boxes. There are similar problems with the recursive chmod, even if it is smart about files, +x files, and folders. We need to have suguid bit set on directories for the OSL setup to maintain group ownership of newly created files and directories (pwolanin, to answer your question: this bit means to inherit the group from parent inode instead of working group of the process owner). Also related to this is the need to have everything g+w. This is pretty common in shared webspace environments where a client doesn't have root.
Anyhow, I was thinking this could be solved outside drupal code as it's pretty site-specific with a script (unless the /release portion is considered to be site-specific to D.o anyhow).
-Eric
#15
@emsearcy: yeah, this chmod would just be on the skeleton directoy we create by checking out a workspace from cvs, just before we run tar. and the chown i was planning to do via the tar option to specify the uid/gid, not as an actual chown, since the packaging script doesn't run as root (thank god!). ;)