Clearly error when ownership check fails when walking parent directories to find a Taskfile

[deviantintegral]

I ran into a tricky issue where Task wasn't finding an expected Taskfile: https://github.com/orgs/ddev/discussions/6273

What was confusing to me is that https://taskfile.dev/next/usage/#running-a-taskfile-from-a-subdirectory says

it will walk up the file tree until it finds one (similar to how git works)

I think it's common for this to refer to git not crossing mounted file systems when looking for a .git directory. It wasn't clear to me that this would also involve ownership checks, which is done here: https://github.com/go-task/task/blob/40d77156df28e87c7cded7d99f312d98257439fc/taskfile/taskfile.go#L148-L150

I assume this is all to prevent potential security issues like the one in Git https://github.blog/2022-04-12-git-security-vulnerability-announced/.

It'd be great if Task could either:

• Clearly say why it stopped walking parent directories.
• Or, if we don't need to check ownership then don't.

[NikitaCOEUR]

Same problem on my side, an issue in a GITHUB ACTION CI running in a container.

I am working in a child directory of the GitHub repository, and the owner is different between :

• the root directory of the repo (owned by the UID of the user running the container [1001 for the runners hosted by GitHub])
• and child directories (owned by user root : https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user) because it is root who executes the actions of the GitHub Action checkout within the container.

Also, if no Taskfile is found by going up from the child directories to the root of the repository, no Taskfile is found at the root either since the owner has changed...

Only workaround: execute the task by targeting the Taskfile directly:

task --taskfile "${GITHUB_WORKSPACE}/Taskfile.yml" ...

[solidDoWant]

I ran into this as well, using vscode dev containers on Windows. Repo gets mounted to /workspaces/<dir name>. This directory is owned by root, with perms set to 0o777. All files within the directory are owned by the vscode user. As a result, I cannot run task from any subdirectory.

It'd really be great if either the check was removed, or there was a global option (env var preferably) to disable it.