Project

General

Profile

Bug #4630

Try several permissions during installation

Added by Julio Montoya over 7 years ago. Updated about 7 years ago.

Status:
Bug resolved
Priority:
Normal
Category:
-
Target version:
Start date:
20/04/2012
Due date:
% Done:

100%

Estimated time:
Spent time:
Complexity:
Normal
SCRUM pts - complexity:
?

Associated revisions

Revision a76f22e1 (diff)
Added by Julio Montoya over 7 years ago

Adding permissions feedback at the beggining of the installation see #4630

Revision 00e4ab7e (diff)
Added by Yannick Warnier about 7 years ago

Fixed files/dirs permissions detection at install time - closes #4630

History

#1

Updated by Yannick Warnier over 7 years ago

The idea here is to find out, during the installation, which permissions are acceptable to create new directories that can later be opened with a php file in there.

To test that, the requirement would be something like (during the real installation, at the end of the process):
  • set 0777 and 0666
  • create a test directory courses/TEST/
  • create a file courses/TEST/index.php which contains:
    <?php echo "hello";?>
    (with permissions as defined last)
  • open a loop ($test = false; while ($test == false)...)
  • execute a $f = file_get_content($root_web.'/courses/TEST/index.php'); (this might be prohibited if allow_url_fopen if off)
  • check if $f == 'hello'
  • if not, start the loop again with 0755, then 0775, then 0770, then 0750 then 0700
  • if there is no success, set permissions as 0777 and 0666 anyway and leave it to the user
  • if one of these does work, set the permissions in settings_current to the ones which worked and proceed with the installation
#2

Updated by Yannick Warnier over 7 years ago

I'm not sure if http://php.net/umask is really useful in this case (I don't think so).
In any case, see the mechanism for writing files with a specific permission in the process to create a new course (add_course.lib.inc.php) as it re-uses the same rules.

#3

Updated by Julio Montoya over 7 years ago

  • Status changed from Assigned to Needs more info
  • Assignee changed from Julio Montoya to Yannick Warnier
  • % Done changed from 0 to 10

I don't think this is a good idea, the script will not be 100% accurate because chamilo will be installed in different environments so sometimes
it will show a message that's fine and it will not work, or sometimes it would work .. etc

I propose to build a page to test the course creation in the platform admin, but again that will not be 100% accurate ... but at least it will help some admins...

#4

Updated by Yannick Warnier over 7 years ago

I don't understand why this would not be accurate. There are about 5 possibilities to be tested, and we would be repeating exactly the same action that would be required afterwards: create a directory + create a file.
There is not even one chance of non-accuracy doing it this way:
  • you try creating a directory and "absorb" the possible error using $r = @mkdir(), then you check the error (with the result of the function call, $r)
  • if it works, then you "continue;" and move to file creation
  • if it didn't, then you try creating the directory again with other permissions until it works
  • then you start the same process with the file
  • then you delete the file and the directory (which you can do because you could create them)

Again, no chance of error and at least 1000 more Chamilo portals installed in the following 6 months... :-)

#5

Updated by Yannick Warnier over 7 years ago

Just to make sure I am understood...

$course_dir = dirname(__FILE__).'/../../courses';
$perms_dir = array('0777', '0755', '0775', '0770', '0750', '0700');
$perms_fil = array('0666', '0644', '0664', '0660', '0640', '0600');

$dir_perm_verified = '0777';
foreach ($perms_dir as $perm) {
  $r = @mkdir($course_dir.'/test',$perm);
  if ($r === true) { 
    $dir_perm_verified = $perm;
    break;
  }
}
$fil_perm_verified = '0666';
foreach ($perms_fil as $perm) {
  $r = @touch($course_dir.'/test/test.txt',$perm);
  if ($r === true) { 
    $fil_perm_verified = $perm;
    break;
  }
}
// If both failed, then it remains to default values
// Store $dir_perm_verified and $fil_perm_verified in database as the default permissions for new dirs and files

#6

Updated by Yannick Warnier over 7 years ago

  • Status changed from Needs more info to Assigned
  • Assignee changed from Yannick Warnier to Julio Montoya
#7

Updated by Julio Montoya over 7 years ago

  • Status changed from Assigned to Needs more info
  • Assignee changed from Julio Montoya to Yannick Warnier
  • % Done changed from 10 to 80

Adding validation when the installation begins

#8

Updated by Julio Montoya over 7 years ago

  • Subject changed from Try several permissions during installation (umask) to Try several permissions during installation
#9

Updated by Yannick Warnier over 7 years ago

  • Status changed from Needs more info to Feature implemented
  • Assignee changed from Yannick Warnier to Julio Montoya
  • % Done changed from 80 to 100

Verified by Yannick :-)

#10

Updated by Yannick Warnier about 7 years ago

  • Status changed from Feature implemented to Assigned
  • Assignee changed from Julio Montoya to Yannick Warnier

Re-opening this one because the permissions are stored in the database as '504' instead of '0770' for the directories, and '432' instead of '660' for files.

This is because 504 is (in decimal) the octal value of '770'.

#11

Updated by Yannick Warnier about 7 years ago

  • Status changed from Assigned to Needs testing
  • % Done changed from 100 to 90

Applied in changeset r18853.

#12

Updated by Yannick Warnier about 7 years ago

  • Status changed from Needs testing to Bug resolved
  • % Done changed from 90 to 100

Also available in: Atom PDF