gitea and read-only filsystems

[micheelengronne]

Gitea wants to modify files even if they are present and with the content gitea wants to put in.

Therefore, Gitea breaks on read-only filesystems (like an hardened docker container.)

My problem is simple.

This method wants to modify a .gitconfig file:

gitea/modules/git/git.go

Line 109 in 9a2e47b

func Init(ctx context.Context) error {

It runs even if the .gitconfig file exists with the correct content.

Is it possible to stop that behaviour ?

Thanks.

[CirnoT]

We rely on git config --global to make changes to Git config file

[micheelengronne]

Yes, but can we disable this method when the file already exists ?

[zeripath]

Just set the HOME environment variable as appropriate to somewhere that can be changed.

[CirnoT]

Yes, but can we disable this method when the file already exists ?

No, because we don't know whether correct values are set or not. The fact that file exists tells us nothing. The .gitconfig is supposed to be writable should new version introduce some new config to be set there.

[micheelengronne]

My usecase happens in a container environment. A new version is introduced by creating a new container image, not updating the existing one.

[micheelengronne]

I tried to do an init container that sets everything and a container with gitea web but still the gitea web cli wants to use this method.

It is a security issue as it forces to use a read-write filesystem for just a file that can easily be commmited in a git.

Can we, at least, have an option to use gitea web and other production-running state commands in a read-only filesystem ?

[zeripath]

@micheelengronne have you set the HOME environment variable appropriately?

[micheelengronne]

Changing the HOME variable is not a solution either. In an immutable hardened container, only data should change, nothing else.

[micheelengronne]

So, what can change is the content of ROOT according to the config cheat sheet.

[micheelengronne]

I am sorry to be strict on that. But this is an absolute condition to make gitea run in security hardened infrastructures. Containers must work with read-only FS and read-only configurations and secrets.

[zeripath]

Right the issue is that Git is making the change to the file.

We are limited in how we can tell Git to look for its .gitconfig.

Git uses HOME to determine the global gitconfig which we use to set various global settings and to look up various things.

So I ask again, have you tried setting the HOME variable to a mutable place?

[zeripath]

If that works then can consider if there is a place for using ROOT to artificially change the HOME for git etc. but without knowing that then we're likely leading down a blind alley and we might have to think about if we need to set things a different way eg. through the default args system

[micheelengronne]

To be sure we talk about the same thing. If I move HOME, I move my user directory, right ? So, I move all configurations in it ?

Did I understand correctly ?

In that way, configurations are not immutables and that will not pass hardened security tests.

Why can't we have a way to include a .gitconfig file containing the same content and for the method to check if the file exists with the correct content prior to create it ?

[zeripath]

No I mean just set the HOME environment variable when you run gitea

[micheelengronne]

But that will screw up my user directory.

For instance, my user is git. I put this file content in /home/git/.gitconfig.

[user]
	name = Gitea
	email = gitea@fake.local
[core]
	quotepath = false
	commitGraph = true
[gc]
	writeCommitGraph = true

Then the init method should not try to write this file.

Do you suggest, I move HOME to /home/git/mutable and make this directory writable ?

If it works that's better than nothing but that will still break the security hardening check as .gitconfig is also a configuration file.

I try.

[micheelengronne]

That works but that's not really the best solution. It would be far better to test if the file exists with the correct values before trying to create it.

If a gitea update occurs that change the file content, the CI job that creates the docker (podman) image would break so future compatibilities would be ensured by that way.

[micheelengronne]

BTW, the 2 first git executions do what I think is the correct way to do.

gitea/modules/git/git.go

Line 112 in 83e9ac5

for configKey, defaultValue := range map[string]string{"user.name": "Gitea", "user.email": "gitea@fake.local"} {

They check if the values exist and they are the same than the ones provided and they execute the git command if one of these assertions is false.

The problem is for these lines:

gitea/modules/git/git.go

Line 126 in 83e9ac5

if _, stderr, err := process.GetManager().Exec("git.Init(git config --global core.quotepath false)",

gitea/modules/git/git.go

Line 132 in 83e9ac5

if _, stderr, err := process.GetManager().Exec("git.Init(git config --global core.commitGraph true)",

gitea/modules/git/git.go

Line 137 in 83e9ac5

if _, stderr, err := process.GetManager().Exec("git.Init(git config --global gc.writeCommitGraph true)",

They do not check so they always try to write.

I am not fluent enough in go to do it myself right now.

[zeripath]

So any configuration in $HOME/.gitconfig can be overridden by a repository's local "project" git config ($GITEA_REPOSITORIES/owner/name.git/config) including in particular diff.tool. Gitea needs to be able to change these config files in order to manage mirrors and remotes amongst other things - and we regularly create temporary repositories which git gives a local project config. I'm not saying that we shouldn't make changing $HOME/.gitconfig unnecessary - but unless you can get to the point that these local project config files are controllable or removable - which I haven't been able to find a way of doing - locking down the $HOME/.gitconfig is of very limited use. $HOME/.gitconfig is the GLOBAL config only in that it provides defaults to the local project git configs - it cannot and does not override local project git config.

[micheelengronne]

I know that. But that was not the point. Anyway, thanks for the commit.