Details

      Description

      At the moment eZ Platform requires Flysystem 0.5.12. The last version of Flysystem is 1.0.20, among other thing, recent versions allow to configure the permission of the created directories and files that would be useful (see EZP-25595 for instance and the corresponding note added in INSTALL.md).

      A pull-request that updates the version has been opened, in order to see the amount of work required: https://github.com/ezsystems/ezpublish-kernel/pull/1695.

        Issue Links

          Activity

          Hide
          Eduardo Fernandes (Inactive) added a comment -

          Yeap, it's possible.

          Check http://stackoverflow.com/questions/3997641/why-cant-php-create-a-directory-with-777-permissions

          The mode is modified by your current umask, which is 022 in this case.
          The way the umask works is a subtractive one. You take the initial permission given to mkdir and subtract the umask to get the actual permission:

          0777 - 0022 = 0755 (rwxr-xr-x)

          If you don't want this to happen, you need to set your umask temporarily to zero so it has no effect. You can do this with the following snippet:

          $oldmask = umask(0);
          mkdir("test", 0777);
          umask($oldmask);

          The first line changes the umask to zero while storing the previous one into $oldmask. The second line makes the directory using the desired permissions and (now irrelevant) umask. The third line restores the umask to what it was originally.

          See the PHP doc for umask and mkdir for more details.

          Show
          Eduardo Fernandes (Inactive) added a comment - Yeap, it's possible. Check http://stackoverflow.com/questions/3997641/why-cant-php-create-a-directory-with-777-permissions The mode is modified by your current umask, which is 022 in this case. The way the umask works is a subtractive one. You take the initial permission given to mkdir and subtract the umask to get the actual permission: 0777 - 0022 = 0755 (rwxr-xr-x) If you don't want this to happen, you need to set your umask temporarily to zero so it has no effect. You can do this with the following snippet: $oldmask = umask(0); mkdir ( "test" , 0777); umask( $oldmask ); The first line changes the umask to zero while storing the previous one into $oldmask. The second line makes the directory using the desired permissions and (now irrelevant) umask. The third line restores the umask to what it was originally. See the PHP doc for umask and mkdir for more details.
          Hide
          Gunnstein Lye added a comment -

          Thanks Eduardo, this is what I had vague memories of The 1.0.24 flysystem does reset the umask like this though, so it should work:
          https://github.com/thephpleague/flysystem/blob/1.0.24/src/Adapter/Local.php#L351
          We should dig more before concluding here.

          Show
          Gunnstein Lye added a comment - Thanks Eduardo, this is what I had vague memories of The 1.0.24 flysystem does reset the umask like this though, so it should work: https://github.com/thephpleague/flysystem/blob/1.0.24/src/Adapter/Local.php#L351 We should dig more before concluding here.
          Hide
          Eduardo Fernandes (Inactive) added a comment -

          changelog.md

          1.0.4 - 2015-06-07
          Fixed
          [Adapter\Ftp] Now handles windows FTP servers.
          [Adapter\Local] Symlinks are now explicitly not supported, this was previously broken.
          [Adapter\Ftp] Detecting whether a path is a directory or not is more reliable.
          [Adapter\SynologyFtp] Has been renamed to Ftpd (The original class still exists for BC).
          [Filesystem] Not uses getAdapter internally to aid extension.
          [Adapter\Local] Now uses umask when creating directories to make it more reliable.
          [Misc] Coding style fixes.

          I checked the code. As far as I saw, they only reset umask t in the createDir function. The creation of files should still be affect by umask. And that explains why [~rui.silva@ez.no] tests were so weird in what concerned files.

          On the other hand, check the getVisibility function.

          public function getVisibility($path)
          {
          	$location = $this->applyPathPrefix($path);
          	clearstatcache(false, $location);
          	$permissions = octdec(substr(sprintf('%o', fileperms($location)), -4));
          	$visibility = $permissions & 0044 ? AdapterInterface::VISIBILITY_PUBLIC : AdapterInterface::VISIBILITY_PRIVATE;
          	return compact('visibility');
          }

          I'm not sure about it, but I think this can explain the problem saw by Rui with the folder creation.

          I say that because for folders creation it respects the mask ignoring umask but won't give rwx permissions to others. If you check the getVisibility function, it is reducing permissions to others, exactly what Rui detected.

          Show
          Eduardo Fernandes (Inactive) added a comment - changelog.md 1.0.4 - 2015-06-07 Fixed [Adapter\Ftp] Now handles windows FTP servers. [Adapter\Local] Symlinks are now explicitly not supported, this was previously broken. [Adapter\Ftp] Detecting whether a path is a directory or not is more reliable. [Adapter\SynologyFtp] Has been renamed to Ftpd (The original class still exists for BC). [Filesystem] Not uses getAdapter internally to aid extension. [Adapter\Local] Now uses umask when creating directories to make it more reliable. [Misc] Coding style fixes. I checked the code. As far as I saw, they only reset umask t in the createDir function. The creation of files should still be affect by umask. And that explains why [~rui.silva@ez.no] tests were so weird in what concerned files. On the other hand, check the getVisibility function. public function getVisibility( $path ) { $location = $this ->applyPathPrefix( $path ); clearstatcache(false, $location ); $permissions = octdec( substr (sprintf( '%o' , fileperms ( $location )), -4)); $visibility = $permissions & 0044 ? AdapterInterface::VISIBILITY_PUBLIC : AdapterInterface::VISIBILITY_PRIVATE; return compact( 'visibility' ); } I'm not sure about it, but I think this can explain the problem saw by Rui with the folder creation. I say that because for folders creation it respects the mask ignoring umask but won't give rwx permissions to others. If you check the getVisibility function, it is reducing permissions to others, exactly what Rui detected.
          Hide
          Gunnstein Lye added a comment -

          getVisibility isn't used when creating files/dirs, and seems to me that what it does is simply to return VISIBILITY_PUBLIC if permissions include group/other readability.

          I tested using chmod manually, the way flysystem does in setVisibility(). Turns out chmod is not affected by umask when using a specific mask (2nd parameter). So still a mystery to me.

          Show
          Gunnstein Lye added a comment - getVisibility isn't used when creating files/dirs, and seems to me that what it does is simply to return VISIBILITY_PUBLIC if permissions include group/other readability. I tested using chmod manually, the way flysystem does in setVisibility(). Turns out chmod is not affected by umask when using a specific mask (2nd parameter). So still a mystery to me.
          Hide
          Rui Silva (Inactive) added a comment -

          Ok. In light of all this new information of the mechanisms of how the permissions feature is working on flysystem, I deem it best to close this issue and regard all this discussion and subsequent information for further testing, at the time EZP-25912 arrives QA queue, since this is already besides the scope of this jira.
          Thank you all for your findings, this shall be useful for EZP-25912.
          Tested and approved by QA for master (the flysystem update).

          Show
          Rui Silva (Inactive) added a comment - Ok. In light of all this new information of the mechanisms of how the permissions feature is working on flysystem, I deem it best to close this issue and regard all this discussion and subsequent information for further testing, at the time EZP-25912 arrives QA queue, since this is already besides the scope of this jira. Thank you all for your findings, this shall be useful for EZP-25912 . Tested and approved by QA for master (the flysystem update).

            People

            • Assignee:
              Unassigned
              Reporter:
              Damien Pobel (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 hour, 45 minutes
                1h 45m