Posted by gabrielinux on January 3, 2009 at 6:15am
| Project: | cryptpw |
| Version: | 6.x-2.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | pillarsdotnet |
| Status: | closed (fixed) |
Issue Summary
I am using PHP5 and Drupal 6. I configured the module with all the defaults (UID=99, GUID=99, etc.). Although my maildir has rwx permissions for owner, group and other, this module can't create the maildir files for each user. It can create the folder with the user's ID with no problems (e.g., 1) but then it doesn't have permissions to create directories inside. I think the problem is that the module is creating directories with only user rwx permissions, but since the UID is 99 (nobody), it can't touch it after that.
Help?
Comments
#1
After reading the documentation for the mkdir() function, it seems servers with safe_mode on need a tweak around the mkdir() call. Before callking mkdir(), you need to temporarily set umask to zero using umask(0). I revised the code of the _cryptpw_maildirmake() function as follows, and it fixed the problem:
function _cryptpw_maildirmake($maildir) {foreach(array('cur','new','tmp') as $d) {
$old_umask = umask(0);
if (!mkdir("$maildir/$d",0700,TRUE)) {
drupal_set_message(
t('Could not create directory %d.',
array('%d'=>"$maildir/$d")
)
);
umask($oldumask);
return FALSE;
}
}
}
You might want to include this in the next release....
Regards,
Gabriel Monge-Franco
Security+ Certified Professional
http://gabriel.mongefranco.com
#2
Thanks. I'll be releasing an updated version shortly.
#3
#4
The problem is that the _cryptpw_maildirmake() function does not return a value when it is successful. When the function is called on line 292, the return value is checked, and since it is empty, results in a failure. Not only did I not need the umask fix, but it didn't fix the problem for me. Adding a
return TRUE;before the final closing brace is all that is necessary.#5
The attached patch fixes this problem, plus a related one that happens when editing an existing user's account.
#6
Applied to -dev.
#7
Automatically closed -- issue fixed for 2 weeks with no activity.