WorkingDirectory/GITEA_WORK_DIR is ignored, leading to push error

[bagasme]

Gitea Version

commit d6f4820

Git Version

2.33.0

Operating System

Debian 11

How are you running Gitea?

Built from source with Go 1.17.2, Node 14.17.6 (npm 6.14.15), GNU Make 4.2.1 on Ubuntu 20.04. Gitea instance runs on Debian 11 LXD container (host is Ubuntu 20.04) with systemd service.

Database

PostgreSQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

(not relevant)

Description

Whenever I push to my Gitea instance via git push, I got this error:

2021/11/04 11:05:59 ...s/setting/setting.go:695:NewContext() [F] Failed to create the directory for app data path '/opt/gitea/data'
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

It seems like Gitea ignores WorkingDirectory directive (systemd) and/or GITEA_WORK_DIR environment variable and attempts to create data directory on Gitea prefix (/opt/gitea), which can't be written by git user that runs Gitea.

I can clone (and possibly pull) from Gitea instance, though.

The log doesn't log anything for this issue, so it isn't relevant.

This issue can't be reproduced on try instance.

Screenshots

No response

[lunny]

Could you paste your systemctl service file?

[zeripath]

How are you pushing?

HTTP, HTTPS, Internal or external SSH.

Have you run the update authorized keys and hooks task?

[bagasme]

How are you pushing?

HTTP, HTTPS, Internal or external SSH.

Have you run the update authorized keys and hooks task?

I push via SSH and also run the mentioned task, but no fix.

[bagasme]

Could you paste your systemctl service file?

Here's the service file:

# Gitea service

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
###
# Don't forget to add the database service requirements
###
#
#Requires=mysql.service
#Requires=mariadb.service
#Requires=postgresql.service
#Requires=memcached.service
#Requires=redis.service
#
###
# If using socket activation for main http/s
###
#
#After=gitea.main.socket
#Requires=gitea.main.socket
#
###
# (You can also provide gitea an http fallback and/or ssh socket too)
#
# An example of /etc/systemd/system/gitea.main.socket
###
##
## [Unit]
## Description=Gitea Web Socket
## PartOf=gitea.service
##
## [Socket]
## Service=gitea.service
## ListenStream=<some_port>
## NoDelay=true
##
## [Install]
## WantedBy=sockets.target
##
###

[Service]
# Modify these two values and uncomment them if you have
# repos with lots of files and get an HTTP error 500 because
# of that
###
LimitMEMLOCK=infinity
LimitNOFILE=65535
RestartSec=2s
Type=simple
User=git
Group=git
WorkingDirectory=/var/gitea/
# If using Unix socket: tells systemd to create the /run/gitea folder, which will contain the gitea.sock file
# (manually creating /run/gitea doesn't work, because it would not persist across reboots)
#RuntimeDirectory=gitea
ExecStart=/opt/gitea/gitea web --config /etc/gitea/app.ini
Restart=always
Environment=USER=git HOME=/srv/git GITEA_WORK_DIR=/var/gitea
Environment=PATH=/opt/git/bin:/bin:/sbin:/usr/bin:/usr/sbin
# If you want to bind Gitea to a port below 1024, uncomment
# the two values below, or use socket activation to pass Gitea its ports as above
###
#CapabilityBoundingSet=CAP_NET_BIND_SERVICE
#AmbientCapabilities=CAP_NET_BIND_SERVICE
###

[Install]
WantedBy=multi-user.target

[zeripath]

Your problem is not at the systemd level but at the authorized_keys level. Either gitea serv or gitea hook are causing the problem.

There are several options:

1. Add ROOT to your app.ini
2. Adjust your SSH_AUTHORIZED_KEYS_COMMAND_TEMPLATE to set the workpath in there with -w
3. Use the FHS compliant script to wrap the gitea binary and run that instead.
4. Compile and builld a FHS compliant gitea with the appropriate LDFLAGS as per building from source.

[bagasme]

Your problem is not at the systemd level but at the authorized_keys level. Either gitea serv or gitea hook are causing the problem.

There are several options:

1. Add ROOT to your app.ini

2. Adjust your SSH_AUTHORIZED_KEYS_COMMAND_TEMPLATE to set the workpath in there with `-w`

3. Use the FHS compliant script to wrap the gitea binary and run that instead.

4. Compile and builld a FHS compliant gitea with the appropriate LDFLAGS as per building from source.

I followed 2). I set SSH_AUTHORIZED_KEYS_COMMAND_TEMPLATE = {{.AppPath}} -w {{.AppWorkPath}} --config={{.CustomConf}} serv key-{{.Key.ID}}.

Now I get (when trying to push a copy of gitea.git):

Enumerating objects: 167, done.
Counting objects: 100% (167/167), done.
Delta compression using up to 4 threads
Compressing objects: 100% (51/51), done.
Writing objects: 100% (99/99), 58.63 KiB | 3.66 MiB/s, done.
Total 99 (delta 85), reused 61 (delta 48)
remote: 2021/11/07 09:44:28 ...s/setting/setting.go:695:NewContext() [F] Failed to create the directory for app data path '/opt/gitea/data'
To gitnode.io:bagas/gitea.git
 ! [remote rejected]     main -> main (pre-receive hook declined)
error: failed to push some refs to '[email protected]:bagas/gitea.git'

It seems like generated pre-receive hook doesn't pass -w parameter, although I have tried to resynchronize hook via admin dashboard.

[zeripath]

yup unfortunately it looks like the hooks don't get the work-path option.

Would it be possible to try one of the other options I presented?

[bagasme]

@zeripath option 3 and 4 isn't applicable here.

For option 3, I tested by manually running the FHS script:

$ GITEA_WORK_DIR=/tmp /usr/local/bin/gitea

It returns error:

/usr/local/bin/gitea: line 40: /root/GITEA_WORK_DIR=/tmp: No such file or directory

When I read the offending line, I see exec -a , which execute $GITEA_WORK_DIR as command instead of as environment variable set to $GITEA.

Maybe it's error in the script?

[zeripath]

Damn,

Try changing:

gitea/contrib/fhs-compliant-script/gitea

Line 40 in 3be156f

exec -a "$0" GITEA_WORK_DIR="${GITEA_WORK_DIR:-$WORK_DIR}" "$GITEA" $CONF_ARG "$@"

to:

 GITEA_WORK_DIR="${GITEA_WORK_DIR:-$WORK_DIR}" exec -a "$0"  "$GITEA" $CONF_ARG "$@" 

[wxiaoguang]

Is the problem resolved? and ... should we fix the contrib/fhs-compliant-script/gitea?

[zeripath]

should we fix the contrib/fhs-compliant-script/gitea?

Just done so in #17846