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:

task/taskfile/taskfile.go

Lines 148 to 150 in 40d7715

	// Error if we reached the root directory and still haven't found a file
	// OR if the user id of the directory changes
	if path == parentPath || (parentOwner != owner) {

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.

[trulede]

Did either of you ever make progress, or learn some new details when running in docker?

I personally run Task in container environments (specifically devcontainers) and its fine. But the user-id issue and mounts can be tricky. Its possible the check (on user-id) exists because Task does create temporary files and this might fail in some cases. (but not all).

If we can pin downs some more detail, it could be an idea to add an environment variable to manage that. Similar to the existing TASK_TEMP_DIR envar.

[solidDoWant]

I did not. I ran into enough issues with taskfiles that I just stopped using it entirely. No one single issue - it was death by a thousand cuts.

[deviantintegral]

This was very much an edge case for us, and hasn’t come up since. The worst was how it was silent behaviour - I think a log message, even if it was only in verbose mode would meet our needs.

[trulede]

The code has changed quite a bit, its not trivial to implement this ... but it looks OK.

~/git$ task --list-all
task: No Taskfile found at "" (or any of the parent directories until ownership changed). Run `task --init` to create a new Taskfile.