Problem/Motivation

One of the hook collector pass tests writes to core/modules/user/tests/modules/user_hooks_test/user_hooks_test.info.yml

This changes the permissions which inadvertently get committed. See https://git.drupalcode.org/project/drupal/-/merge_requests/13331#note_59...

Let's just reset the permissions in teardown to prevent this.

Steps to reproduce

run this test locally: core/tests/Drupal/KernelTests/Core/Hook/HookCollectorPassTest.php
Check permissions

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3549419

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

nicxvan created an issue. See original summary.

berdir’s picture

I haven't look at the test, many other tests set up modules in vfs instead of changing real files, would that be an option here?

nicxvan’s picture

We can't use VFS.

It's specifically a test for symlinks and vfs does not support symlinks.

mstrelan’s picture

If I'm following this right, the code in question is this:

foreach (scandir("core/modules/user/tests/modules/user_hooks_test") as $item) {
  $target = "$this->siteDirectory/$item";
  if (!file_exists($target)) {
    symlink(realpath("core/modules/user/tests/modules/user_hooks_test/$item"), $target);
  }
}

For a start, symlink() expects $target as the first parameter, but I think we're just using the wrong name for the variable. The target is where the symlink points to, which is the file in core/modules. The link we're creating is written to $this->siteDirectory which should be in sites/simpletest, which should be gitignored.

If I'm mistaken, can you point to where the test is writing to a file that is checked in to the repository?

mstrelan’s picture

Oh I found it.

In \Drupal\KernelTests\KernelTestBase::tearDown

// Delete test site directory.
$callback = function (string $path) {
  @chmod($path, 0700);
};

This is passed to \Drupal\Core\File\FileSystem::deleteRecursive and it's applied to every file. Perhaps we could just fix that to now chmod symlinks? I'm curious why we need to chmod a file that is going to be deleted anyway, if we have permission to set the permissions then surely we can just delete it?

mstrelan’s picture

Status: Active » Needs review
nicxvan’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

I thought this was actually a different issue, but it works!

I'm glad you found that (ironically I worked on both issues you tracked down).

I'm going to ping @alexpott since he worked on the bit introduced here and make sure I'm not forgetting something.

This looks pretty straightforward though.

https://git.drupalcode.org/project/drupal/-/commit/ed78b812e179b3bc52371... and #3482449: \Drupal\Core\File\FileSystem::deleteRecursive() will follow symlinks and remove files outside the directory it is deleting for reference.

nicxvan’s picture

Status: Reviewed & tested by the community » Needs review

Whoops didn't mean to change status

nicxvan’s picture

Status: Needs review » Reviewed & tested by the community

I think we can mark this now. Looks good to me and @alexpott signed off too.

I've updated credit.

longwave’s picture

Version: 11.x-dev » 11.3.x-dev
Status: Reviewed & tested by the community » Fixed

This probably is eligible for backport but not sure it's worth the effort.

Committed and pushed cb176c7426f to 11.x and 1b5f6d95e32 to 11.3.x. Thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

  • longwave committed 1b5f6d95 on 11.3.x
    test: #3549419 Add permission reset after test writes to file
    
    By:...

  • longwave committed cb176c74 on 11.x
    test: #3549419 Add permission reset after test writes to file
    
    By:...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.