Failed to load .gitconfig

[ms-boom]

trafficstars

Duplicates

• [X] I have searched the existing issues

Current behavior 😯

If .gitconfig contains includeIf option

[includeIf "gitdir:~/projects/"]
path = .gitconfig-projects

then onefetch fails on start with error:

$ onefetch 
Error: Failed to load the git configuration

Caused by:
    Permission denied (os error 13)

Expected behavior 🤔

No response

Steps to reproduce 🕹

1. add some option "includeIf" in ~/.gitconfig
2. run onefetch

Additional context/Screenshots 🔦

No response

Possible Solution 💡

No response

[spenserblack]

:thinking:

I wonder if this stems from git2 or gix (cc @Byron).

[Byron]

Thanks for the heads-up!

What does Git do in the same situation? I presume it just works? Or does it print anything? Also, which platform are you on and which version of onefetch are you using?

gitoxide will resolve such includes and I assume it could find .gitconfig-projects and failed to read it due to a permission denied error, which is something the git program should surface as well.

I think what could be done here is that gitoxide can be taught to be allowed to ignore errors during includes-processing, but doing so would still be the decision of onefetch, the governing application. It will definitely help to see what git does here.

Thanks for your help.

[spenserblack]

In my attempts to recreate this, I made a config (path = fakepath) and removed read and write permissions from that file. Both onefetch and git itself failed due to being unable to read the file.

@ms-boom Does git itself raise a permission error? If not, could you give us steps to take to reproduce this error?

[ms-boom]

I use

git version 2.34.1

onefetch 2.19.0

OS: Ubuntu 22.04.4 LTS

full example of .gitconfig:

[pull]
rebase = true

[includeIf "gitdir:~/projects/work/"]
path = .gitconfig-work

[includeIf "gitdir:~/projects/pet-projects/"]
path = .gitconfig-pet-projects

[core]
        editor = vim

This is correct for Git. Everything is fine with file permissions too. I use this configuration at work.

If i remove options with "includeIf" onefetch works fine. The error is reproduced even if .gitconfig-work and .gitconfig-pet-projects are empty. So it looks like the problem is in the includeIf option.

[spenserblack]

Sorry, I mean a way to recreate the file permissions so we can test this out. Could you try running this?

ls -l ~/.gitconfig ~/.gitconfig-projects ~/.gitconfig-work ~/.gitconfig-pet-projects

[Byron]

That's true, thus far we can only reproduce the variant where both onefetch and git have trouble reading the include file, but not what you are describing unfortunately.

Seeing the result of the line proposed by @spenserblack would be very helpful.

The error is reproduced even if .gitconfig-work and .gitconfig-pet-projects are empty. So it looks like the problem is in the includeIf option.

It would always try to read them which seems to be the problem. But it should be a problem for git as well, but maybe git has special permissions, like the SUID bit set?

Maybe let's extend the line above to:

ls -l ~/.gitconfig ~/.gitconfig-projects ~/.gitconfig-work ~/.gitconfig-pet-projects "$(which git)"

[ms-boom]

ls -l ~/.gitconfig ~/.gitconfig-projects ~/.gitconfig-work ~/.gitconfig-pet-projects "$(which git)"

-rw-rw-r-- 1 ms-boom ms-boom     254 Feb 22 20:37 /home/ms-boom/.gitconfig
-rw-rw-r-- 1 ms-boom ms-boom     243 Jan 29 21:27 /home/ms-boom/.gitconfig-pet-projects
-rw-rw-r-- 1 ms-boom ms-boom     220 Jan 10 15:32 /home/ms-boom/.gitconfig-work
-rwxr-xr-x 1 root     root     3702168 Jul  7  2023 /usr/bin/git

[Byron]

Thanks a lot! It doesn't look like git is actually run as root, so onefetch and git should have the same permissions when launched. Yet, onefetch can't read a file and probably fails right here when opening a configuration file it determined exists.

And for that I have no explanation except if onefetch would find a file that git doesn't actually find. But at this time there is no facility to debug this.

If you would be willing to get a local developer setup I could provide patches for gitoxide that would help shed some light. It's not incredibly involved, but would have you clone onefetch, clone gitoxide, create configuration in onefetch for it to use the local version of gitoxide, and then apply various patches to that local clone to try onefetch against.

Without that remote debugging, and without being able to reproduce that locally (i.e. Git works but onefetch fails), I don't think there is more I can do.

Please let me know @ms-boom if you want to try such remote debugging with me.

[spenserblack]

For the sake of completeness, do we want to see the file stats of onefetch? (ls -l "$(which onefetch)")

[ms-boom]

Sorry, I forgot that I installed the package via snap, and it seems that this is the issue. I got the project sources, built the package locally, and everything works correctly. But when running via snap there is an error described above.

ls -l "$(which onefetch)"

lrwxrwxrwx 1 root root 13 May 18 09:35 /snap/bin/onefetch -> /usr/bin/snap

ls -l /usr/bin/snap
-rwxr-xr-x 1 root root 16138392 May 29  2023 /usr/bin/snap

[Byron]

That's definitely bringing us closer, thanks so much for trying and validating the 'build-from-source' route. Since we have come such a long way, I feel a little more information might be able to solve the riddle.

Would you be able to check which files are opened, and how, via strace? This should reveal exactly what's happening, even though I am not entirely sure it will reveal which user a file operation effectively runs at.

If the strace log still seems odd, maybe displaying changes to the effective user (see further down in the chatlog) will finally shed some light on what's going on, particularly if the same strace command is used with the locally built version of onefetch.

My hypothesis is that the effective user of the snap-version truly isn't entitled to read that file, whereas the effective user that is executing it would be (as seen when using the locally built version of onefetch).

[spenserblack]

This is actually very helpful. I know very little about snaps (rarely install them, have never built one myself), but IIRC they have limited permissions compared to "traditional" executables, and can raise permission denied errors when even trying to read from directories outside of /home/USER and maybe a few others.

@Byron, do you think gix might be looking in a directory that the snap wouldn't have access to in this scenario? And could that be affected by the presence of the includeIf option? Perhaps it's trying to include from an unexpected directory instead of $HOME?

[spenserblack]

Shortly after submitting that comment I figured I should actually read our snapcraft config :laughing: Again, I know nothing about this config file at this moment, but it looks like we have to explicitly request access to git config files: https://github.com/o2sh/onefetch/blob/c83a9592dd6315c85f7383055adb84d579ad2fa0/snap/snapcraft.yaml#L26-L35

I also don't use the includeIf option, so IDK about its capabilities. Is it able to point to a directory outside of $HOME? If so, I imagine we'll never be completely secure from edge cases involving snap permissions and includeIf options.

Sorry, @Byron, please ignore my last question about gix :slightly_smiling_face:

[Byron]

That's great detective work! I think the strace would show that it does indeed just try to access one of the included files, but since these of course aren't included in the snap manifest, it fails to do so.

Something that should definitely improve is the error message, which should at least show which file it tried to access. Besides that, I don't think there is much that can be done as the amount of possibilities for custom includes is so wide-ranging that full access would have to be granted.

[spenserblack]

Yeah, 100% agree. Additionally, maybe the error message could include possible reasons that it failed to access the file:

• Do you have access?
• Did you install this as a snap and are you using a custom git config path?
• etc.

[Byron]

I started small and added the path in addition to a message alluding to the failure to include the given configuration file, along with the source of the issue which would look like before.

With that, issues like these will be less opaque as well and it might be more obvious what the issue is. However, it also looks like there is nothing actionable to do here :/.

[spenserblack]

@ms-boom I don't think we can do much to resolve this issue besides making the error message more clear and directing users to alternative installation methods if this happens. What do you think? Would a warning on the snap installation instructions be sufficient? If so, we'd be happy to get a PR!

[o2sh]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.