January 2005 - Development - lists.drupal.org

[drupal-devel] theme contribution
by stevew＠etmeli.us 27 Jan '05

27 Jan '05

Good day, I'd like to throw the themes I've developed into the mix on Drupal.org. I've applied for a CVS account, once a couple of weeks ago with some plans, and once again this week after releasing the themes. It is quite possible that I missed an email back, but I was wondering what is the usual lag between applying for CVS access and getting it? Perhaps it is a subtle hint that I should not have CVS, but it didn't work. :) I have always been subtlety-impaired. Steve Wright http://theme.etmeli.us/ -- When I could find voice, I shrieked aloud in agony, "Either this is madness or it is Hell." "It is neither," calmly replied the voice of the Sphere, "it is Knowledge." _Flatland_, by Edwin A. Abbott

2 1

[drupal-devel] Hook_settings() confusion
by Michael Jervis 27 Jan '05

27 Jan '05

Hi, According to the API (http://drupaldocs.org/api/head/function/hook_settings) "This hook provides an administrative interface for controlling various settings for this module. A menu item for the module under "site configuration > modules" will appear in the administrative menu when this hook is implemented." However, in my mt-blacklist module I'm working on, I have defined the function, but there is no link anywhere on the menu for the admin. Nor for spam.module which also defines it. Directly entering the url to the settings page for the module however works fine. Any idea what I've missed? (4.5.2 install, CVS Spam) Mike

1 0

[drupal-devel] [feature] Taxonomy Cloud
by Dan Robinson 27 Jan '05

27 Jan '05

Neil asked me to cross post this here - We (CivicActions) are about to begin work on a "Taxonomy Cloud" or transport mechanism. The goal is not about creating taxonomies but allowing them to be easily shared amongst a network of sites. The goal is to allow folks to define a shared taxonomy and then access content between sites. Please see <dev.civicactions.net/?q=node/114> for my initial write up of the "Taxonomy Cloud". This is something that is a deliverable for CivicGroups and we will begin coding early next week. Please comment at <dev.civicactions.net/?q=forum/34> Thanks, Dan P.S. The original message is posted at <http://civicspacelabs.org/node/view/4981>

1 0

[drupal-devel] Re: [contributions:kbahey] /modules/feedback feedback.module
by Dries Buytaert 27 Jan '05

27 Jan '05

drupal-cvs(a)drupal.org wrote: > Log message: > Added configurable path. For example, it can be 'contact' instead of > the default 'feedback'. > > This is useful, for example, when you replace an existing module with > this one, and you do not want to get 404 errors, and preserve the > same old path. Isn't that a little crufty? It sounds to me as if using path aliases would be better suited for this task. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] needed documentation for block module for 4.6
by Moshe Weitzman 27 Jan '05

27 Jan '05

I am upgrading recipe.module now like a good citizen. I find these instructions unlikely: "The only required changes to modules implementing hook_block() is to be careful about what is returned. Do not return anything if $op is not 'list' or 'view'". But those are the only $op values according to http://drupaldocs.org/api/head/function/hook_block. Perhaps we need to document 'configure' and other operations? I have not followed these changes very closely.

6 7

Re: [drupal-devel] Module for Review
by Boris Mann 27 Jan '05

27 Jan '05

On Wed, 26 Jan 2005 19:56:21 -0000, Michael Jervis <mike(a)fuckingbrit.com> wrote: > I've written another auth module. > > Contributions/modules/bloggerauth > > Could someone review it prior to me posting a project request. It's > working > here: > http://www.fuckingbrit.com/other_sites/drupal/user/login Works For Me (tm). I logged in with both Blogger and Livejournal accounts. -- Boris Mann http://www.bryght.com

1 0

[drupal-devel] [feature] Forum admin screen updates
by Boris Mann 27 Jan '05

27 Jan '05

Project: Drupal Version: cvs Component: forum.module Category: feature requests Priority: normal Assigned to: ccourtne Reported by: ccourtne Updated by: Boris Mann Status: patch Is this going to get committed? Talk about it on CS developers list. Also: can this separate multiple forums? Can it be extended to support multiple forums? Boris Mann Previous comments: ------------------------------------------------------------------------ August 28, 2004 - 22:50 : ccourtne Attachment: http://drupal.org/files/issues/forumadmin.patch (18.5 KB) Added admin screens to maintain forums instead of forcing the user to add a taxonomy. In addition the patch hides the forum taxonomy from the categories screen since the forum module does not support all features of taxonomies. The patch still needs clean up work for comments and the delete function needs to remove forum topics when you remove a forum, but I wanted to get it out for review. This patch requires the latest forum speed up patch found here http://drupal.org/node/view/10308. Craig ------------------------------------------------------------------------ September 8, 2004 - 15:25 : ccourtne Attachment: http://drupal.org/files/issues/forumadmin2.patch (22.84 KB) New patch that properly deletes forum topics when the forum is deleted, has all code comments, and updates the help text. ------------------------------------------------------------------------ September 8, 2004 - 15:40 : ccourtne some screen shots of the admin screens http://homepage.mac.com/ccourtne/drupal/forum_add_forum.png http://homepage.mac.com/ccourtne/drupal/forum_add_forum.png http://homepage.mac.com/ccourtne/drupal/forum_add_container.png http://homepage.mac.com/ccourtne/drupal/forum_config.png ------------------------------------------------------------------------ September 8, 2004 - 15:42 : ccourtne One more screenshot. http://homepage.mac.com/ccourtne/drupal/forum_overview.png ------------------------------------------------------------------------ September 8, 2004 - 16:21 : ccourtne updating to patch status ------------------------------------------------------------------------ September 8, 2004 - 21:17 : Dries Looks good! ------------------------------------------------------------------------ September 14, 2004 - 21:08 : ccourtne Attachment: http://drupal.org/files/issues/forumadmin3.patch (22.77 KB) Screenshots have a new home. http://www.dawnsedge.com/ccourtne/drupal/forum_add_forum.png http://www.dawnsedge.com/ccourtne/drupal/forum_overview.png http://www.dawnsedge.com/ccourtne/drupal/forum_add_container.png http://www.dawnsedge.com/ccourtne/drupal/forum_config.png Also updated the patch for current CVS head. ------------------------------------------------------------------------ September 20, 2004 - 06:19 : walkah not only do i think this looks very good, but i also think image.module folks should maybe take notice :) (hint hint). oh, and weren't we gonna split taxonomy.module into taxonomy.inc + taxonomy.module at one point? ------------------------------------------------------------------------ September 21, 2004 - 10:47 : Dries I'm going to commit as soon CVS HEAD is opened up for development. In the mean time, keep refining this patch so other modules can learn from it. -- View: http://drupal.org/node/10425 Edit: http://drupal.org/project/comments/add/10425

1 0

[drupal-devel] cvs log messages
by no-reply＠zind.net 26 Jan '05

26 Jan '05

File: /translations/it/taxonomy-module.po 1.8 Date: January 26, 2005 - 22:11 User: michelef Drupal 4.5.2 translation; ongoing. ---------------------------------------------------------------------- File: Date: January 26, 2005 - 19:54 User: themike Working version (no support for modblog, their server is being strange with packets that work for blogger.com, must be library incompatibility..) ---------------------------------------------------------------------- File: /translations/it/general.po 1.7 Date: January 26, 2005 - 19:53 User: michelef Drupal 4.5.2 translation; complete. ---------------------------------------------------------------------- File: /translations/it/forum-module.po 1.6 /translations/it/menu-module.po 1.7 /translations/it/node-module.po 1.8 /translations/it/poll-module.po 1.5 /translations/it/queue-module.po 1.6 /translations/it/search-module.po 1.7 /translations/it/story-module.po 1.7 Date: January 26, 2005 - 19:51 User: michelef Drupal 4.5.2 translation; complete. ---------------------------------------------------------------------- File: /translations/it/blogapi-module.po 1.7 Date: January 26, 2005 - 19:49 User: michelef Drupal 4.5.2 translation; ongoing. ---------------------------------------------------------------------- File: Date: January 26, 2005 - 16:32 User: latpro hook_init removed ---------------------------------------------------------------------- File: /modules/feedback/INSTALL 1.6 /modules/feedback/README.txt 1.4 Date: January 26, 2005 - 15:21 User: kbahey Added more info on where to submit bug reports on Drupal project page. ---------------------------------------------------------------------- File: Date: January 26, 2005 - 15:20 User: kbahey Added more info on original authors, and where to submit issues on Drupal's project page. ---------------------------------------------------------------------- File: /modules/print/po/nl.po 1.1.2.1 DRUPAL-4-5 Date: January 26, 2005 - 13:55 User: km km - changed line numbers and added strings from print.tpl.php ---------------------------------------------------------------------- File: /modules/print/po/print.pot 1.1.2.1 DRUPAL-4-5 Date: January 26, 2005 - 13:52 User: km km - changed strings, added strings from print.tpl.php ---------------------------------------------------------------------- File: /modules/captcha/captcha.module 1.10 Date: January 26, 2005 - 13:44 User: arnabdotorg Fixed incorrect writing of variables to session ---------------------------------------------------------------------- File: /modules/print/INSTALL.txt 1.1.2.2 DRUPAL-4-5 /modules/print/MAINTAINERS.txt 1.1.2.1 DRUPAL-4-5 /modules/print/print.module 1.2.2.2 DRUPAL-4-5 /modules/print/print.tpl.php 1.1.2.2 DRUPAL-4-5 Date: January 26, 2005 - 13:18 User: km km - included changes from HEAD ---------------------------------------------------------------------- File: /modules/print/print.module 1.5 Date: January 26, 2005 - 13:02 User: km km - changed link ---------------------------------------------------------------------- File: /modules/print/print.tpl.php 1.5 Date: January 26, 2005 - 12:59 User: km km - improved layout and localized strings ---------------------------------------------------------------------- File: Date: January 26, 2005 - 12:56 User: ber This sandbox directory is made to collect all the efforts for the new weblinks system. A lot of modules are (being) developed, but all are scattered. OVer mail we had decided to collaborate and make it one project. This sandbox is the home of that project ---------------------------------------------------------------------- File: /modules/captcha/captcha.module 1.9 /modules/captcha/README.txt 1.7 Date: January 26, 2005 - 12:28 User: arnabdotorg Fixed anon user check ---------------------------------------------------------------------- File: Date: January 26, 2005 - 12:01 User: MegaGrunt Fix incompatibility between MySQL 4.1.x and 4.0.x in SQL dump ---------------------------------------------------------------------- File: /modules/news_page/news_page.module 1.4 /modules/news_page/README.txt 1.3 Date: January 26, 2005 - 11:03 User: MegaGrunt Code clean up ---------------------------------------------------------------------- File: /modules/massmailer/engines/phplist/bin/phplist 1.1.2.3 DRUPAL-4-5 Date: January 26, 2005 - 01:21 User: crunchywelch rollback executable file to previous version ---------------------------------------------------------------------- File: /modules/massmailer/engines/phplist/bin/phplist 1.3 Date: January 26, 2005 - 01:20 User: crunchywelch rollback executable file to previous version ---------------------------------------------------------------------- File: /modules/feedback/feedback.module 1.26 Date: January 26, 2005 - 01:14 User: kbahey Added configurable path. For example, it can be 'contact' instead of the default 'feedback'. This is useful, for example, when you replace an existing module with this one, and you do not want to get 404 errors, and preserve the same old path. ---------------------------------------------------------------------- File: /modules/listhandler/listhandler.module 1.53.2.2 DRUPAL-4-5 Date: January 26, 2005 - 00:18 User: drumm http://drupal.org/node/15910 [^[:digit:]]* does in fact match zero digits followed by digits. So if you have a list with tid 1 and a list with tid 12, both are matched and spammed. [[:>:]] is a bit better choice. This patch does that. It also fixes code style. ---------------------------------------------------------------------- File: /modules/listhandler/listhandler.module 1.57 Date: January 26, 2005 - 00:18 User: drumm http://drupal.org/node/15910 [^[:digit:]]* does in fact match zero digits followed by digits. So if you have a list with tid 1 and a list with tid 12, both are matched and spammed. [[:>:]] is a bit better choice. This patch does that. It also fixes code style. ---------------------------------------------------------------------- File: Date: January 25, 2005 - 23:30 User: latpro improve declaration Script fixed ---------------------------------------------------------------------- File: /database/updates.inc 1.86 Date: January 25, 2005 - 21:54 User: dries - Wrong update slipped in. ---------------------------------------------------------------------- File: Date: January 25, 2005 - 21:45 User: latpro ---------------------------------------------------------------------- File: Date: January 25, 2005 - 21:45 User: latpro ---------------------------------------------------------------------- File: /CHANGELOG.txt 1.60 Date: January 25, 2005 - 21:41 User: dries - Updating the CHANGELOG.txt a little. ----------------------------------------------------------------------

1 0

[drupal-devel] [bug] files folder created with incorrect permissions
by Morbus Iff 26 Jan '05

26 Jan '05

Project: Drupal Version: cvs Component: file system Category: bug reports Priority: normal Assigned to: Morbus Iff Reported by: Anonymous Updated by: Morbus Iff Status: patch Arnab and I talked about this on IRC, and his proposed solution sounded great ("go, go comment on the Issue and I'll make the patch. yay!"), no UI necessary, hoohah. Well, I dunno what crack I was smoking, but this doesn't actually work. If Drupal is wwwrun:nobody, then 1) will create wwwrun:nobody/640, 2) will be unnecessary, and 3) would succeed, causing MIN to be set as the DEFAULT, and morbus:users would still be out in the cold for FTP access. So, uh, ignore comment #14. It doesn't work. Back to comment #12. Thoughts? Morbus Iff Previous comments: ------------------------------------------------------------------------ September 8, 2004 - 13:04 : Anonymous Hi,- > [rreading@tribal html]$ ls -l www/files > total 12 > drwxr----- 2 nobody nobody 4096 Sep 8 12:22 pictures > drwxrwxrwx 2 rreading users 4096 Sep 8 12:33 tmp > drwxr----- 3 nobody nobody 4096 Sep 8 12:33 upload the problem is very strange, and might even be a nasty drupal bug: As of the CVS version we decided to let drupal generate the folders itself, so that Joe User needs not to use ssh or ftp to make /configure various folders. So these were generated by PHP and thus have the wrong permission. The user PHP is a differnet user in this case, and something that PHP created is inacessible to us. I am aware that this is sierverspecific, but its annoying enought for me (and probably others) not to ignore. Regards, Ber ------------------------------------------------------------------------ November 18, 2004 - 21:46 : dtan Any update on this. . ?? I recently installed the 4.5 Head and the problem still exists. Recommendations on how to actually change the permission on the folder? dtan ------------------------------------------------------------------------ November 28, 2004 - 10:53 : killes(a)www.drop.org The apache user did create this directories. So it is natural that they have the apache user "nobody" as owner. Drupal should be able to handle this just file. Can we close this report? ------------------------------------------------------------------------ November 28, 2004 - 10:58 : Bèr Kessels No, please do not close. Its a bug IMO. Because a lot of (v)hosts do not put apache in the same group as the FTP user. It will work, file uplaods etc will work for Drupal, but you, as user, cannot access the files anymore by FTP. But even worse, you cannot remove your drupal installation, without intervention of root (or the server maintainer). I had two "empty" domains with 30 MB of files taking up space for 3 months. Another domain will not let me mirror (backup) anything because of this. ------------------------------------------------------------------------ November 29, 2004 - 22:55 : svemir If PHP/apache can create these folders, it should be able to remove them as well. Perhaps an option somewhere to remove folders created by Drupal? Maybe a button next to the place in administration where the folder is specified. And also maybe the creation of the folders should be optional in the first place... ------------------------------------------------------------------------ January 19, 2005 - 20:52 : Morbus Iff This just bit me today too. Installed the banner.module, and ensured that my files/ directory was 777, with the owner as gangrene:user. Uploaded a new banner, and for various reasons, it didn't work. As I started to investigate, I found that the files/banner directory, which was "successfully" created (success determined by "I can access files uploaded in that folder via a URL) was not visible to my FTP server (at this point, proFTPd, though I've not yet tested on vsftpd). One of ProFTPds feature is to hide folders that do not have the executable bit set. The default permissions of Drupal is not to set these, per file_check_directory in includes/file.inc. So, my newly Drupal-created files/banners folder was given the permissions of (where wwwrun and nogroup are the Apache user/group). drwxrw---- 2 wwwrun nogroup 88 Jan 19 20:03 banners Since there's no execute for everyone, and since the "gangrene" user is not part of "nogroup", I was not able to see, access, or modify the newly created folder. I had to manually issue chmod('files/banners', 0761) to even look at the blasted thing. My recommendation is to change the file_check_directory chmod to 0771, which should create drwxrwx--x permissions. The extra execute permission on the "nogroup" is harmless, and allows ProFTPd to display it (in this case to "nogroup", but also perhaps to the "users" group on other systems), and the execute permission for everyone is absolutely required for me to see it in under ProFTPD. These permissions are giving any extra (or damaging) permissions to anyone, but merely following the expectations of various FTP servers concerning "what a directory is". There's a similar bug related to uploaded files, but I've not yet found the code for that one. ------------------------------------------------------------------------ January 19, 2005 - 20:55 : Morbus Iff Grrrr... "these permissions are NOT giving any extra (or damaging) permissions". ------------------------------------------------------------------------ January 19, 2005 - 21:12 : Morbus Iff To revise my previous statement, it would be best to use perms 0765, which adds "read" access to the "everyone" group. The correction is simple: if we want to /see/ the folder in FTP, then we also want to see /inside/ the folder via FTP. Again, I don't believe this change really gives extra dangerous permissions to anyone, merely grants the same permission to an authenticated FTP user (if a file upload can be seen on the web by people who know its there, then the same access should be applied to FTP users with the right knowledge [ie., un/pw]). ------------------------------------------------------------------------ January 19, 2005 - 21:29 : Morbus Iff Alrighty, hunted down the file (not directory) related problem. Unlike directories, which require us to enter a mode, file uploads are not specified, thus they take on the default umask of the web server's user (in my case, wwwgroup:nogroup, 640). This further causes problems with FTP viewing because "everyone" has no permission (in my case, since I'm a part of the "users" group, I can not view, modify, delete, mirror, etc. files that have been uploaded through Drupal). This has been tracked down to file_copy() (includes/file.inc) and the following lines, which copy the uploaded file from the temp directory ($source) to the final destination ($dest). if (!@copy($source, $dest)) { drupal_set_message(t('File copy failed.'), 'error'); return 0; } My proposal is to add an explicit chmod after the copy, granting read permission to "everyone", something to the effect of the following, which will give read and write to the webserver process, read to the webserver group, and read to everyone (ie., little old me, not of the webserver group). if (!@copy($source, $dest)) { drupal_set_message(t('File copy failed.'), 'error'); return 0; } chmod($dest, 0644). ------------------------------------------------------------------------ January 19, 2005 - 21:40 : Morbus Iff Attachment: http://drupal.org/files/issues/fileperm.patch (606 bytes) Attached is a patch for Drupal 4.5.1 that implements these changes (directory is set for 764, not 765 - the mode in my previous comment was [another] error). Last time I contributed a patch, I created a bug so please review extra carefully. ------------------------------------------------------------------------ January 20, 2005 - 11:27 : Morbus Iff In chatting about this with #drupal, I'm thinking that something more than just "sane defaults" needs to be enabled. The patch I just submitted still has one "fatal" flaw: it doesn't allow write permissions for the FTP user. This was ultimately deliberate (more chance of accepting the patch with less dangerous permission, and the assumption that a Drupal-controlled upload also offered a Drupal-controlled deletion), but still isn't ideal. Unfortunately, with SuEXEC servers and various configurations, there is no SAFE default: on one hand you're giving 666 to everyone because you have to (wwwrun:nogroup) and on the other, 666 is too much (if you're running under SuEXEC, then gangrene:users/640 is right, and 666 is wrong). I think the only way this will be truly solved is with user intervention, which means umask settings for file/directory in the "Files" section of admin/setting. This is also the same solution that Movable Type uses, which allows two special settings in its mt.cfg: # When creating files and directories, Movable Type uses umask settings to # control the permissions set on the files. The default settings for file # creation (HTMLUmask, DBUmask, and UploadUmask) are 0111; for directory # creation (DirUmask), the default is 0000. You should not change these # settings unless you are running MT under cgiwrap or suexec, or some other # scenario where the MT application runs as you; in addition, you should not # change these settings unless you know what they mean, and what they do. # # DBUmask 0022 # HTMLUmask 0022 # UploadUmask 0022 # DirUmask 0022 # # In addition to controlling permissions via umask settings, you can also # use the HTMLPerms and UploadPerms settings to control the default # permissions for files created by the system (either as output files or # uploaded files). The only real use of this is to turn on the executable bit # of files created by the system--for example, if MT is generating PHP files # that need to have the executable bit turned on, you could set HTMLPerms # to 0777. The default is 0666. You should not change these settings unless # you know what they mean, and what they do. # # HTMLPerms 0777 # UploadPerms 0777 For our needs, we'd really only need a DirectoryUmask and a FileUmask option. Is this an amicable solution to anyone? If I get you a patch, will this be implemented in Drupal 4.6? ------------------------------------------------------------------------ January 21, 2005 - 11:58 : Morbus Iff After further reflection, I'm now leaning toward: * leave the current Drupal permissions as they are (ignore my previous patch). * add GUI options to change the directory/file mode (per last comment). The GUI would be two sets of dropdown boxes, one for files and one for directories. The automatically chosen option for Files would be "read/write for Drupal only" (umask: 0640), with another option of "read/write for everybody" (umask: 0666). The directory options would be the same with the following umasks 0771 or 0777. ------------------------------------------------------------------------ January 21, 2005 - 12:26 : Morbus Iff This is a list of known possibilities that the proposed patch/UI addresses. In each case, the proposed solution above will, BY DEFAULT, create directories as 771 and files as 640. These possibilities run through a number of ownership possibilities, and any solutions in regards to an FTP user. Possibility #1 (traditional): * Drupal runs as user wwwrun, group nogroup. * FTP user IS NOT a member of group nogroup. * FTP user WILL see a Drupal-created directory. * FTP user WILL NOT be able to modify/view Drupal-created directory. * FTP user WILL NOT be able to modify/view Drupal-created files. * Solution: Toggle "read/write for everybody" for files/directories. * Pro: 777/666 is the only way this problem could be solved for FTP user. Possibility #2 (suexec/suPHP). * Drupal runs as user FTPuser, group users. * FTP user IS a member of group users. * FTP user WILL see a Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created files. * Solution: None necessary. New defaults are fine. Possibility #3 (oddball configuration): * Drupal runs as user wwwrun, group users. * FTP user IS a member of group users. * FTP user WILL see a Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created directories. * FTP user WILL be able to view Drupal-created files. * FTP user WILL NOT be able to modify/delete Drupal-created files. * Solution: Toggle "read/write for everybody" for files/directories. * Con: Gives "everybody" too many permissions. * Pro: This is an oddball config I've never seen. Possibility #4 (oddball configuration): * Drupal runs as user FTPuser, group nogroup. * FTP user IS NOT a member of group nogroup. * FTP user WILL see a Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created files. * Solution: None necessary. New defaults are fine. * Pro: This is an oddball config I've never seen. ------------------------------------------------------------------------ January 26, 2005 - 16:12 : arnabdotorg Here's one way: Define: MIN_FILE_PERMS, MID_FILE_PERMS, MIN_DIR_PERMS, MID_DIR_PERMS (e.g. 640, 666, 711, 771) In the "admin" page (where "files" is checked for writability) 1. Create a file 2. Set it to MIN_FILE_PERMS 3. Delete it 4. If 3 fails, Set it to MID_FILE_PERMS. If does not fail, Set variable for DRUPAL_FILE_PERMS to MIN_FILE_PERMS 5. Delete it 6. if 5 fails, throw error that files are not writable/deletable. 7. If 5 does not fail, Set variable for DRUPAL_FILE_PERMS to MID_FILE_PERMS Do the same thing for directories. Also, I wont mind 3x2 checkboxes for Directories and File perms for more detailed control _in addition_ to the above algo (the above algo can be the "validate" part of the 3x2. ------------------------------------------------------------------------ January 26, 2005 - 16:19 : arnabdotorg lol, ignore this, it's useless. I'm attributing my sense of logic to it being 3:00 am here. -- View: http://drupal.org/node/10658 Edit: http://drupal.org/project/comments/add/10658

1 0

[drupal-devel] [bug] files folder created with incorrect permissions
by arnabdotorg 26 Jan '05

26 Jan '05

Project: Drupal Version: cvs Component: file system Category: bug reports Priority: normal Assigned to: Morbus Iff Reported by: Anonymous Updated by: arnabdotorg Status: patch lol, ignore this, it's useless. I'm attributing my sense of logic to it being 3:00 am here. arnabdotorg Previous comments: ------------------------------------------------------------------------ September 8, 2004 - 18:04 : Anonymous Hi,- > [rreading@tribal html]$ ls -l www/files > total 12 > drwxr----- 2 nobody nobody 4096 Sep 8 12:22 pictures > drwxrwxrwx 2 rreading users 4096 Sep 8 12:33 tmp > drwxr----- 3 nobody nobody 4096 Sep 8 12:33 upload the problem is very strange, and might even be a nasty drupal bug: As of the CVS version we decided to let drupal generate the folders itself, so that Joe User needs not to use ssh or ftp to make /configure various folders. So these were generated by PHP and thus have the wrong permission. The user PHP is a differnet user in this case, and something that PHP created is inacessible to us. I am aware that this is sierverspecific, but its annoying enought for me (and probably others) not to ignore. Regards, Ber ------------------------------------------------------------------------ November 19, 2004 - 02:46 : dtan Any update on this. . ?? I recently installed the 4.5 Head and the problem still exists. Recommendations on how to actually change the permission on the folder? dtan ------------------------------------------------------------------------ November 28, 2004 - 15:53 : killes(a)www.drop.org The apache user did create this directories. So it is natural that they have the apache user "nobody" as owner. Drupal should be able to handle this just file. Can we close this report? ------------------------------------------------------------------------ November 28, 2004 - 15:58 : Bèr Kessels No, please do not close. Its a bug IMO. Because a lot of (v)hosts do not put apache in the same group as the FTP user. It will work, file uplaods etc will work for Drupal, but you, as user, cannot access the files anymore by FTP. But even worse, you cannot remove your drupal installation, without intervention of root (or the server maintainer). I had two "empty" domains with 30 MB of files taking up space for 3 months. Another domain will not let me mirror (backup) anything because of this. ------------------------------------------------------------------------ November 30, 2004 - 03:55 : svemir If PHP/apache can create these folders, it should be able to remove them as well. Perhaps an option somewhere to remove folders created by Drupal? Maybe a button next to the place in administration where the folder is specified. And also maybe the creation of the folders should be optional in the first place... ------------------------------------------------------------------------ January 20, 2005 - 01:52 : Morbus Iff This just bit me today too. Installed the banner.module, and ensured that my files/ directory was 777, with the owner as gangrene:user. Uploaded a new banner, and for various reasons, it didn't work. As I started to investigate, I found that the files/banner directory, which was "successfully" created (success determined by "I can access files uploaded in that folder via a URL) was not visible to my FTP server (at this point, proFTPd, though I've not yet tested on vsftpd). One of ProFTPds feature is to hide folders that do not have the executable bit set. The default permissions of Drupal is not to set these, per file_check_directory in includes/file.inc. So, my newly Drupal-created files/banners folder was given the permissions of (where wwwrun and nogroup are the Apache user/group). drwxrw---- 2 wwwrun nogroup 88 Jan 19 20:03 banners Since there's no execute for everyone, and since the "gangrene" user is not part of "nogroup", I was not able to see, access, or modify the newly created folder. I had to manually issue chmod('files/banners', 0761) to even look at the blasted thing. My recommendation is to change the file_check_directory chmod to 0771, which should create drwxrwx--x permissions. The extra execute permission on the "nogroup" is harmless, and allows ProFTPd to display it (in this case to "nogroup", but also perhaps to the "users" group on other systems), and the execute permission for everyone is absolutely required for me to see it in under ProFTPD. These permissions are giving any extra (or damaging) permissions to anyone, but merely following the expectations of various FTP servers concerning "what a directory is". There's a similar bug related to uploaded files, but I've not yet found the code for that one. ------------------------------------------------------------------------ January 20, 2005 - 01:55 : Morbus Iff Grrrr... "these permissions are NOT giving any extra (or damaging) permissions". ------------------------------------------------------------------------ January 20, 2005 - 02:12 : Morbus Iff To revise my previous statement, it would be best to use perms 0765, which adds "read" access to the "everyone" group. The correction is simple: if we want to /see/ the folder in FTP, then we also want to see /inside/ the folder via FTP. Again, I don't believe this change really gives extra dangerous permissions to anyone, merely grants the same permission to an authenticated FTP user (if a file upload can be seen on the web by people who know its there, then the same access should be applied to FTP users with the right knowledge [ie., un/pw]). ------------------------------------------------------------------------ January 20, 2005 - 02:29 : Morbus Iff Alrighty, hunted down the file (not directory) related problem. Unlike directories, which require us to enter a mode, file uploads are not specified, thus they take on the default umask of the web server's user (in my case, wwwgroup:nogroup, 640). This further causes problems with FTP viewing because "everyone" has no permission (in my case, since I'm a part of the "users" group, I can not view, modify, delete, mirror, etc. files that have been uploaded through Drupal). This has been tracked down to file_copy() (includes/file.inc) and the following lines, which copy the uploaded file from the temp directory ($source) to the final destination ($dest). if (!@copy($source, $dest)) { drupal_set_message(t('File copy failed.'), 'error'); return 0; } My proposal is to add an explicit chmod after the copy, granting read permission to "everyone", something to the effect of the following, which will give read and write to the webserver process, read to the webserver group, and read to everyone (ie., little old me, not of the webserver group). if (!@copy($source, $dest)) { drupal_set_message(t('File copy failed.'), 'error'); return 0; } chmod($dest, 0644). ------------------------------------------------------------------------ January 20, 2005 - 02:40 : Morbus Iff Attachment: http://drupal.org/files/issues/fileperm.patch (606 bytes) Attached is a patch for Drupal 4.5.1 that implements these changes (directory is set for 764, not 765 - the mode in my previous comment was [another] error). Last time I contributed a patch, I created a bug so please review extra carefully. ------------------------------------------------------------------------ January 20, 2005 - 16:27 : Morbus Iff In chatting about this with #drupal, I'm thinking that something more than just "sane defaults" needs to be enabled. The patch I just submitted still has one "fatal" flaw: it doesn't allow write permissions for the FTP user. This was ultimately deliberate (more chance of accepting the patch with less dangerous permission, and the assumption that a Drupal-controlled upload also offered a Drupal-controlled deletion), but still isn't ideal. Unfortunately, with SuEXEC servers and various configurations, there is no SAFE default: on one hand you're giving 666 to everyone because you have to (wwwrun:nogroup) and on the other, 666 is too much (if you're running under SuEXEC, then gangrene:users/640 is right, and 666 is wrong). I think the only way this will be truly solved is with user intervention, which means umask settings for file/directory in the "Files" section of admin/setting. This is also the same solution that Movable Type uses, which allows two special settings in its mt.cfg: # When creating files and directories, Movable Type uses umask settings to # control the permissions set on the files. The default settings for file # creation (HTMLUmask, DBUmask, and UploadUmask) are 0111; for directory # creation (DirUmask), the default is 0000. You should not change these # settings unless you are running MT under cgiwrap or suexec, or some other # scenario where the MT application runs as you; in addition, you should not # change these settings unless you know what they mean, and what they do. # # DBUmask 0022 # HTMLUmask 0022 # UploadUmask 0022 # DirUmask 0022 # # In addition to controlling permissions via umask settings, you can also # use the HTMLPerms and UploadPerms settings to control the default # permissions for files created by the system (either as output files or # uploaded files). The only real use of this is to turn on the executable bit # of files created by the system--for example, if MT is generating PHP files # that need to have the executable bit turned on, you could set HTMLPerms # to 0777. The default is 0666. You should not change these settings unless # you know what they mean, and what they do. # # HTMLPerms 0777 # UploadPerms 0777 For our needs, we'd really only need a DirectoryUmask and a FileUmask option. Is this an amicable solution to anyone? If I get you a patch, will this be implemented in Drupal 4.6? ------------------------------------------------------------------------ January 21, 2005 - 16:58 : Morbus Iff After further reflection, I'm now leaning toward: * leave the current Drupal permissions as they are (ignore my previous patch). * add GUI options to change the directory/file mode (per last comment). The GUI would be two sets of dropdown boxes, one for files and one for directories. The automatically chosen option for Files would be "read/write for Drupal only" (umask: 0640), with another option of "read/write for everybody" (umask: 0666). The directory options would be the same with the following umasks 0771 or 0777. ------------------------------------------------------------------------ January 21, 2005 - 17:26 : Morbus Iff This is a list of known possibilities that the proposed patch/UI addresses. In each case, the proposed solution above will, BY DEFAULT, create directories as 771 and files as 640. These possibilities run through a number of ownership possibilities, and any solutions in regards to an FTP user. Possibility #1 (traditional): * Drupal runs as user wwwrun, group nogroup. * FTP user IS NOT a member of group nogroup. * FTP user WILL see a Drupal-created directory. * FTP user WILL NOT be able to modify/view Drupal-created directory. * FTP user WILL NOT be able to modify/view Drupal-created files. * Solution: Toggle "read/write for everybody" for files/directories. * Pro: 777/666 is the only way this problem could be solved for FTP user. Possibility #2 (suexec/suPHP). * Drupal runs as user FTPuser, group users. * FTP user IS a member of group users. * FTP user WILL see a Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created files. * Solution: None necessary. New defaults are fine. Possibility #3 (oddball configuration): * Drupal runs as user wwwrun, group users. * FTP user IS a member of group users. * FTP user WILL see a Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created directories. * FTP user WILL be able to view Drupal-created files. * FTP user WILL NOT be able to modify/delete Drupal-created files. * Solution: Toggle "read/write for everybody" for files/directories. * Con: Gives "everybody" too many permissions. * Pro: This is an oddball config I've never seen. Possibility #4 (oddball configuration): * Drupal runs as user FTPuser, group nogroup. * FTP user IS NOT a member of group nogroup. * FTP user WILL see a Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created files. * Solution: None necessary. New defaults are fine. * Pro: This is an oddball config I've never seen. ------------------------------------------------------------------------ January 26, 2005 - 21:12 : arnabdotorg Here's one way: Define: MIN_FILE_PERMS, MID_FILE_PERMS, MIN_DIR_PERMS, MID_DIR_PERMS (e.g. 640, 666, 711, 771) In the "admin" page (where "files" is checked for writability) 1. Create a file 2. Set it to MIN_FILE_PERMS 3. Delete it 4. If 3 fails, Set it to MID_FILE_PERMS. If does not fail, Set variable for DRUPAL_FILE_PERMS to MIN_FILE_PERMS 5. Delete it 6. if 5 fails, throw error that files are not writable/deletable. 7. If 5 does not fail, Set variable for DRUPAL_FILE_PERMS to MID_FILE_PERMS Do the same thing for directories. Also, I wont mind 3x2 checkboxes for Directories and File perms for more detailed control _in addition_ to the above algo (the above algo can be the "validate" part of the 3x2. -- View: http://drupal.org/node/10658 Edit: http://drupal.org/project/comments/add/10658

1 0