MegaLinter applying fixes sets root:root as the file owner

[kcfedun-fincad]

When running MegaLinter in "fix" mode, it will chown the fixed files to root:root as the file owner. This causes permission issues later when I attempt to make changes to the file through my IDE. Is there a way to have MegaLinter maintain the file user and group ownership when it "fixes" the linting issues?

[Kurt-von-Laven]

I recommend running Docker in rootless mode if possible. See ScribeMD/rootless-docker for a GitHub Action that does this.

[kcfedun-fincad]

I recommend running Docker in rootless mode if possible. See ScribeMD/rootless-docker for a GitHub Action that does this.

This might work for running in GitHub, however, most of us work locally in an Ubuntu 20 WSL development environment. I've tried rootless mode there and had no success. Also, bespoke developer environment tweaks to Docker to get a linter tool to work seem difficult to support long term. Any other less invasive suggestions?

[Kurt-von-Laven]

Yeah, I haven't had any luck with rootless mode in WSL either. I would see if there is an existing issue on either WSL or Docker that you can upvote for rootless mode support. (Feel free to link it here if you find it, and I'll happily upvote it as well.) I'm not sure why, but I haven't encountered the issue with file permissions being modified when running MegaLinter as a pre-commit hook. Otherwise, I think reviving #1485 is the next best option? Not that this is relevant to this problem, but why Ubuntu 20.04 WSL as opposed to Ubuntu 22.04 WSL?

[kcfedun-fincad]

Not that this is relevant to this problem, but why Ubuntu 20.04 WSL as opposed to Ubuntu 22.04 WSL?

Ubuntu 20.04 WSL only for the reason that we haven't moved to 22.x yet.

[nvuillam]

hmmm I'm no linux expert, but what about if we add a config param that would change back updated files ?

Something like:

UPDATED_FILES_CHOWN: toto

And if such config is found, we do chown toto thefile.xxx

[Kurt-von-Laven]

I wouldn't be surprised if there are some security concerns with chowning to an arbitrary string, but regardless it seems unlikely that all developers on a project would share a username in the case where they are running MegaLinter locally?

[kcfedun-fincad]

Work in progress, but I've added these Pre and Post commands to .mega-linter.yml. The basic theory is that the permissions on .gitignore are likely to be correctly set for the developer's workspace, so we scrape the user and group IDs from inside the container (they'll resolve to UIDs and GIDs, not friendly names because these users don't exist inside the container). We save the UID:GID combination into a temporary txt file. The linter then runs and fixes files as necessary, but changes those fixed file's ownership to root:root. We can then run the post command to find these files and chown them back, then delete the temporary perms.txt file.

.mega-linter.yml
---

...
PRE_COMMANDS:
  - command: |-
      echo $(ls -lah .gitignore | sed 's/\s\+/ /g' | cut -d ' ' -f3,4 | sed 's/ /\:/') > perms.txt
    cwd: "workspace"

POST_COMMANDS:
  - command: |-
      find . -user root -group root -exec chown $(cat perms.txt) {} \;
      rm perms.txt
    cwd: "workspace"
...

[nvuillam]

If it works that could be a nice workaround, but having such behavior directly embedded within megalinter would feel more optimal ^^

[Kurt-von-Laven]

There are some test failures associated with my PR that will require some debugging, but I believe it is conceptually correct to simply instruct Docker not to run as root on the command line. #1485 is also conceptually correct, and ideally we would do both, but I suspect that will require significantly more work to iron out all the details and get the tests passing.

This doesn't relate to the permissions problem directly, but folks who are using WSL may be interested in the "clone of clones" development technique we use to boost local MegaLinter performance while retaining access to Windows-only tools.