Debian 9.6 AMD64: Segfault on start at os/user.Current (1.7.0+) #3287

@zeripath commented on GitHub (May 3, 2019):

Are you running Gitea on a raspberry pi? If so there is a known problem with the arm7 binary and you need to use arm6.

If not what kernel version do you have? If it's very old you're likely to need to build Gitea yourself as we build on Ubuntu 18.04.

Finally, please don't run 1.7.0 there are a number of security issues in that version and we recommend 1.8 if not at least 1.7.6 (there are fixes in 1.8 that cannot be ported back to 1.7.6)

@zeripath commented on GitHub (May 3, 2019): Are you running Gitea on a raspberry pi? If so there is a known problem with the arm7 binary and you need to use arm6. If not what kernel version do you have? If it's very old you're likely to need to build Gitea yourself as we build on Ubuntu 18.04. Finally, please don't run 1.7.0 there are a number of security issues in that version and we recommend 1.8 if not at least 1.7.6 (there are fixes in 1.8 that cannot be ported back to 1.7.6)

GiteaMirror commented

@hendrikbl commented on GitHub (May 6, 2019):

I'm on a virtual machine running Debian 9.6 x86_64 with kernel version 4.9.0-4-amd64.

I tried version 1.7.0, 1.7.6 and 1.8. They all give me the same error.

@hendrikbl commented on GitHub (May 6, 2019): I'm on a virtual machine running Debian 9.6 x86_64 with kernel version 4.9.0-4-amd64. I tried version 1.7.0, 1.7.6 and 1.8. They all give me the same error.

GiteaMirror commented

@zeripath commented on GitHub (May 6, 2019):

Ok.

Under what user are you trying to run Gitea?
And where? Things don't make sense.

The segfault looks like it's happening when Gitea tries to get the current username. That implies that you're running Gitea as a weird user.

Although you state:

/usr/local/bin/gitea web -c /etc/gitea/app.ini

Gitea seems to be trying get its config:

/usr/local/bin/custom/conf/app.ini

Not in /etc...

What does your service file look like?

Does Gitea run when you just run it as a normal user from a normal directory?

@zeripath commented on GitHub (May 6, 2019): Ok. Under what user are you trying to run Gitea? And where? Things don't make sense. The segfault looks like it's happening when Gitea tries to get the current username. That implies that you're running Gitea as a weird user. Although you state: `/usr/local/bin/gitea web -c /etc/gitea/app.ini` Gitea seems to be trying get its config: `/usr/local/bin/custom/conf/app.ini` Not in `/etc`... What does your service file look like? Does Gitea run when you just run it as a normal user from a normal directory?

GiteaMirror commented

@hendrikbl commented on GitHub (May 6, 2019):

I followed the documentation when first installing gitea. So gitea service is running as git user:

root@gitea:~# cat /etc/passwd | grep git
git:x:109:116:Git Version Control,,,:/home/git:/bin/bash

The binary is located at /usr/local/bin. The working directory is /var/lib/gitea/. As seen in the documentation.

Here's my service file: gitea.service

I tried running gitea as root and git from the corresponding home directory but i still get a segfault.

Although you state:

/usr/local/bin/gitea web -c /etc/gitea/app.ini

Gitea seems to be trying get its config:

/usr/local/bin/custom/conf/app.ini

Not in /etc...

Thats my fault. The log I gave you was from running gitea without the -c argument. Here are the three things I tried:

User: git, Directory: /usr/local/bin - Gist
User: git, Directory: /home/git - Gist
User: root, Directory: home/root - Gist

Does Gitea run when you just run it as a normal user from a normal directory?

So the answer to this question is: No, I can't run gitea anywhere. The strange thing is that version 1.6.4 runs everytime on every circumstance. Everything thats newer than that fails.

Edit: Everything here was tested with version 1.8 of gitea.

@hendrikbl commented on GitHub (May 6, 2019): I followed the [documentation](https://docs.gitea.io/en-us/install-from-binary/) when first installing gitea. So gitea service is running as git user: ``` root@gitea:~# cat /etc/passwd | grep git git:x:109:116:Git Version Control,,,:/home/git:/bin/bash ``` The binary is located at `/usr/local/bin`. The working directory is `/var/lib/gitea/`. As seen in the documentation. Here's my service file: [gitea.service](https://gist.github.com/hendrikbl/87e53d46d63aa4a2a010b3870753bf69) I tried running gitea as root and git from the corresponding home directory but i still get a segfault. > Although you state: > >/usr/local/bin/gitea web -c /etc/gitea/app.ini > >Gitea seems to be trying get its config: > >/usr/local/bin/custom/conf/app.ini > >Not in /etc... Thats my fault. The log I gave you was from running gitea without the `-c` argument. Here are the three things I tried: - User: `git`, Directory: `/usr/local/bin` - [Gist](https://gist.github.com/hendrikbl/25140c70a5edec58be8cdb6cbd799daa) - User: `git`, Directory: `/home/git` - [Gist](https://gist.github.com/hendrikbl/9903b5559198fc02f9098789b904f1d2) - User: `root`, Directory: `home/root` - [Gist](https://gist.github.com/hendrikbl/087ac63b54b7913d47b4df24aecc9518) >Does Gitea run when you just run it as a normal user from a normal directory? So the answer to this question is: No, I can't run gitea anywhere. The strange thing is that version 1.6.4 runs everytime on every circumstance. Everything thats newer than that fails. Edit: Everything here was tested with version 1.8 of gitea.

GiteaMirror commented

@sapk commented on GitHub (May 6, 2019):

This thread on discourse seem related: https://discourse.gitea.io/t/solved-segfault-due-to-misconfigured-unix-user/1104

@sapk commented on GitHub (May 6, 2019): This thread on discourse seem related: https://discourse.gitea.io/t/solved-segfault-due-to-misconfigured-unix-user/1104

GiteaMirror commented

https://github.com/golang/go/issues/24787

@zeripath commented on GitHub (May 6, 2019):

Hmm. It looks like this is:

Which if I'm reading correctly causes panic on os/user.Current or Lookup for uid <1000.

Now it seems like it's suggested that we need to add more flags to our static build:

https://github.com/golang/go/issues/24787#issuecomment-387611691

But I bet a simple workaround is to have a uid>=1000. Now you may actually need that in any case because of the SSH requirements - in that if you want to clone over SSH you need to be able to login as that user and run authorized_keys or an authorized keys command which I'm not certain you can do as a uid <1000.

@zeripath commented on GitHub (May 6, 2019): Hmm. It looks like this is: https://github.com/golang/go/issues/24787 Which if I'm reading correctly causes panic on os/user.Current or Lookup for uid <1000. Now it seems like it's suggested that we need to add more flags to our static build: https://github.com/golang/go/issues/24787#issuecomment-387611691 But I bet a simple workaround is to have a uid>=1000. Now you may actually need that in any case because of the SSH requirements - in that if you want to clone over SSH you need to be able to login as that user and run authorized_keys or an authorized keys command which I'm not certain you can do as a uid <1000.

GiteaMirror commented

@sapk commented on GitHub (May 6, 2019):

@zeripath It is a pity that we need an other tag (osusergo) like netgo but if it ensure consistency across env we should add it.

@sapk commented on GitHub (May 6, 2019): @zeripath It is a pity that we need an other tag (`osusergo`) like `netgo` but if it ensure consistency across env we should add it.

GiteaMirror commented

@hendrikbl commented on GitHub (May 6, 2019):

I tried running gitea with a new user with a uid>1000:

root@gitea:/usr/local/bin# grep gitea /etc/shadow
gitea:!:18022:0:99999:7:::
root@gitea:/usr/local/bin# grep gitea /etc/passwd
gitea:x:1003:1002:Gitea,,,:/home/gitea:/bin/bash

Still no luck. I get exactly the same. Current version 1.6.4 runs perfectly, everything above that fails.

Can I use the gitea dump command on my current version, create a fresh install of version 1.8 somewhere else and restore the dump? If that's the case I will try that.

@hendrikbl commented on GitHub (May 6, 2019): I tried running gitea with a new user with a uid>1000: ``` bash root@gitea:/usr/local/bin# grep gitea /etc/shadow gitea:!:18022:0:99999:7::: root@gitea:/usr/local/bin# grep gitea /etc/passwd gitea:x:1003:1002:Gitea,,,:/home/gitea:/bin/bash ``` Still no luck. I get exactly the same. Current version 1.6.4 runs perfectly, everything above that fails. Can I use the `gitea dump` command on my current version, create a fresh install of version 1.8 somewhere else and restore the dump? If that's the case I will try that.

GiteaMirror commented

@lunny commented on GitHub (May 6, 2019):

@hendrikbl That's dump and restore are not guaranteed.

@lunny commented on GitHub (May 6, 2019): @hendrikbl That's dump and restore are not guaranteed.

GiteaMirror commented

@zeripath commented on GitHub (May 6, 2019):

@hendrikbl I assume that by a uid > 1000 you haven't marked the user as a system user?

OK, so I wonder how we test this. I've just downloaded the docker debian:latest and that doesn't replicate the issue with 1.8.0

@zeripath commented on GitHub (May 6, 2019): @hendrikbl I assume that by a uid > 1000 you haven't marked the user as a system user? OK, so I wonder how we test this. I've just downloaded the docker debian:latest and that doesn't replicate the issue with 1.8.0

GiteaMirror commented

@zeripath commented on GitHub (May 6, 2019):

and I've just tried docker pull debian:9.6 and haven't got this issue either and 1.8 and 1.7.6

@zeripath commented on GitHub (May 6, 2019): and I've just tried docker pull debian:9.6 and haven't got this issue either and 1.8 and 1.7.6

GiteaMirror commented

@hendrikbl commented on GitHub (May 6, 2019):

@zeripath correct, I just used adduser and followed the setup without setting a password.

Hmm, have you done everything according to the installation guide? Because that's what I did. I'll see if I can try this on a fresh debian install this week. I'm not sure when I have time for that though.

@hendrikbl commented on GitHub (May 6, 2019): @zeripath correct, I just used `adduser` and followed the setup without setting a password. Hmm, have you done everything according to the [installation guide](https://docs.gitea.io/en-us/install-from-binary/)? Because that's what I did. I'll see if I can try this on a fresh debian install this week. I'm not sure when I have time for that though.

GiteaMirror commented

@zeripath commented on GitHub (May 6, 2019):

OK, I mean I can start from the command line - I think getting systemd started on a debian docker is fairly difficult.

@zeripath commented on GitHub (May 6, 2019): OK, I mean I can start from the command line - I think getting systemd started on a debian docker is fairly difficult.

GiteaMirror commented

@zeripath commented on GitHub (May 6, 2019):

~~Oh I did add a password though...~~ Nope that doesn't seem to matter

@zeripath commented on GitHub (May 6, 2019): ~~Oh I did add a password though...~~ Nope that doesn't seem to matter

GiteaMirror commented

@zeripath commented on GitHub (May 6, 2019):

root@ef9a8c7df397:/home/gitsys# adduser git2
Adding user `git2' ...
Adding new group `git2' (1001) ...
Adding new user `git2' (1001) with group `git2' ...
Creating home directory `/home/git2' ...
Copying files from `/etc/skel' ...
Enter new UNIX password: 
Retype new UNIX password: 
No password supplied
Enter new UNIX password: 
Retype new UNIX password: 
No password supplied
Enter new UNIX password: 
Retype new UNIX password: 
No password supplied
passwd: Authentication token manipulation error
passwd: password unchanged
Try again? [y/N] 
Changing the user information for git2
Enter the new value, or press ENTER for the default
	Full Name []: 
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
Is the information correct? [Y/n] y
root@ef9a8c7df397:/home/gitsys# sudo -u git2 /gitea-1.7.6-linux-amd64 -c /home/git2/custom/conf/app.ini
2019/05/06 13:43:10 [W] Custom config '/home/git2/custom/conf/app.ini' not found, ignore this if you're running first time
2019/05/06 13:43:10 [T] AppPath: /gitea-1.7.6-linux-amd64
2019/05/06 13:43:10 [T] AppWorkPath: 
2019/05/06 13:43:10 [T] Custom path: custom
2019/05/06 13:43:10 [T] Log path: log
2019/05/06 13:43:10 [I] Gitea v1.7.6 built with go1.12.4 : bindata, sqlite, sqlite_unlock_notify
2019/05/06 13:43:10 [I] Log Mode: Console(Info)
2019/05/06 13:43:10 [I] XORM Log Mode: Console(Info)
2019/05/06 13:43:10 [I] Cache Service Enabled
2019/05/06 13:43:10 [I] Session Service Enabled
2019/05/06 13:43:10 [I] SQLite3 Supported
2019/05/06 13:43:10 [I] Run Mode: Development
2019/05/06 13:43:10 [I] Listen: http://0.0.0.0:3000
2019/05/06 13:43:10 Serving [::]:3000 with pid 5021
^C2019/05/06 13:43:12 Exiting pid 5021.

@zeripath commented on GitHub (May 6, 2019): ``` root@ef9a8c7df397:/home/gitsys# adduser git2 Adding user `git2' ... Adding new group `git2' (1001) ... Adding new user `git2' (1001) with group `git2' ... Creating home directory `/home/git2' ... Copying files from `/etc/skel' ... Enter new UNIX password: Retype new UNIX password: No password supplied Enter new UNIX password: Retype new UNIX password: No password supplied Enter new UNIX password: Retype new UNIX password: No password supplied passwd: Authentication token manipulation error passwd: password unchanged Try again? [y/N] Changing the user information for git2 Enter the new value, or press ENTER for the default Full Name []: Room Number []: Work Phone []: Home Phone []: Other []: Is the information correct? [Y/n] y root@ef9a8c7df397:/home/gitsys# sudo -u git2 /gitea-1.7.6-linux-amd64 -c /home/git2/custom/conf/app.ini 2019/05/06 13:43:10 [W] Custom config '/home/git2/custom/conf/app.ini' not found, ignore this if you're running first time 2019/05/06 13:43:10 [T] AppPath: /gitea-1.7.6-linux-amd64 2019/05/06 13:43:10 [T] AppWorkPath: 2019/05/06 13:43:10 [T] Custom path: custom 2019/05/06 13:43:10 [T] Log path: log 2019/05/06 13:43:10 [I] Gitea v1.7.6 built with go1.12.4 : bindata, sqlite, sqlite_unlock_notify 2019/05/06 13:43:10 [I] Log Mode: Console(Info) 2019/05/06 13:43:10 [I] XORM Log Mode: Console(Info) 2019/05/06 13:43:10 [I] Cache Service Enabled 2019/05/06 13:43:10 [I] Session Service Enabled 2019/05/06 13:43:10 [I] SQLite3 Supported 2019/05/06 13:43:10 [I] Run Mode: Development 2019/05/06 13:43:10 [I] Listen: http://0.0.0.0:3000 2019/05/06 13:43:10 Serving [::]:3000 with pid 5021 ^C2019/05/06 13:43:12 Exiting pid 5021. ```

GiteaMirror commented

@zeripath commented on GitHub (May 6, 2019):

Damn if we can't replicate this we can't be sure that osusergo will actually fix it.

@zeripath commented on GitHub (May 6, 2019): Damn if we can't replicate this we can't be sure that osusergo will actually fix it.

GiteaMirror commented