Gitea in docker container ignores USER_GID?

[HansHansen]

Hi.
Running the docker container of Gitea (latest) on my Synology, I realized a wired behavior:

I have configured the container with

USER_UID = 1042 (which is for a local username named “gitea”) and
USER_GID = 100 (default users group)

The docker container binds a local volume (/volume1/testordner/test1) to the container’s mount path: “/data”
The owner of the folder “test1” is the user Gitea.

When I start up the Gitea container, the folder and file privileges are being modified: Within the Synology file browser, a permission for user group “Everybody” is being added (read access). Same for all subfolders that are being created (“gitea” and “git”)

ssh-ing on the nas shows me the group for the corresponding folders has been set to 1000 (→ no valid group on my nas):

admin@nas:/volume1/testfolder/test1$ cat /etc/group
#$_@GID__INDEX@_$65540$
administrators:x:101:admin
avahi:x:84:
backup_users:x:65536:Anton
bind:x:53:
daemon:x:2:daemon,root
dbus:x:81:
docker-users:x:65537:gitea
ftp:x:21:ftp
http:x:1023:
log:x:19:root
lp:x:7:lp
maildrop:x:126:
mysql:x:66:
nobody:x:99:
ntp:x:87:
root:x:0:root
users:x:100:
wheel:x:10:

admin@nas:/volume1/testfolder/test1$ dir
total 0
drwxrwxrwx+ 1 gitea users  22 Jul 10 00:25 .
drwxrwxrwx+ 1 root  root   22 Jul  9 23:35 ..
drwxr-xr-x  1 gitea  1000   8 Jul 10 00:25 git
drwxr-xr-x  1 gitea  1000  14 Jul 10 00:25 gitea
drwx------  1 root  root  312 Jul 10 00:25 ssh

admin@nas:/volume1/testfolder/test1$ cd gitea/
admin@nas:/volume1/testfolder/test1/gitea$ dir
total 0
drwxr-xr-x  1 gitea  1000 14 Jul 10 00:25 .
drwxrwxrwx+ 1 gitea users 22 Jul 10 00:25 ..
drwxr-xr-x+ 1 gitea  1000 14 Jul 10 00:25 conf
drwxr-xr-x+ 1 gitea  1000  0 Jul 10 00:25 log

admin@nas:/volume1/testfolder/test1/gitea$ cd conf
admin@nas:/volume1/testfolder/test1/gitea/conf$ ls -la
total 4
drwxr-xr-x+ 1 gitea 1000   14 Jul 10 00:25 .
drwxr-xr-x  1 gitea 1000   14 Jul 10 00:25 ..
-rw-------  1 gitea 1000 1364 Jul 10 00:25 app.ini

admin@nas:/volume1/testfolder/test1/gitea$ cat /etc/group | grep gitea
docker-users:x:65537:gitea

admin@nas:/volume1/testfolder/test1/gitea$ cat /etc/passwd | grep gitea
gitea:x:1042:100:docker gitea user:/var/services/homes/gitea:/sbin/nologin

I don’t have a clue, why the Group-id I am setting is not being used. Regarding to this here, the alias is correct: gitea/entrypoint at main · go-gitea/gitea · GitHub

Note: I also tried additional group IDs (existing and not existing ones). The group ID that is being set is always 1000. - In result every user has access to the “gitea” and the “git” folder within the mapped folder. That’s something I definitely want to avoid.

Can anybody help me with this issue?

[dachary]

@HansHansen

admin@nas:/volume1/testfolder/test1$ cat /etc/group

Here is a piece of information that may help you move forward with a solution: the groups inside the docker container are using a different file. You can look at it with:

$ docker exec -ti gitea bash
bash-5.1# grep 1000 /etc/group
git:x:1000:git

[HansHansen]

Thx dachary,
within the container, i am getting exactly the same output as you did:

bash-5.1# grep 1000 /etc/group
git:x:1000:git

I’m not an docker expert, but shouldn’t there be a mapping based on my parameters from the inner-container user to an external host-user?
Am I doing something wrong here?

My guess is, synology’s DMS cannot find a local group with id 1000 and, hence, sets the group permission to everybody.

[dachary]

I’d be able to help if only docker was involved. But I have no clue the synology layer is doing on top of docker.

[HansHansen]

well, as I said, I’m not a docker expert…
In general, is my assumption reg. the mapping correct: The host user gitea (id:1042, gip: 100 (users group)) has to be mapped with the USER_UID and USER_GIP inside the container?

Du you, dachary, or maybe also someone else, have a clue why the container uses 1000 (obviously the containers internal group id) as group id and not the set USER_GID= 100 for the mapped volume sub-folders?

I just saw. The user “gitea” has been mapped into the container. Also the UID and GID look ok.

bash-5.1# id gitea                                                                                                                                                             
uid=1042(gitea) gid=100(users) groups=100(users)

inside the container the user/group settings for /data (= shared folder) look like this:

bash-5.1# ls -la ./data/                                                                                                                                                       
total 0                                                                                                                                                                        
dr-xr-xr-x    1 1026     users           22 Jul 10 14:27 .                                                                                                                     
drwxr-xr-x    1 root     root           148 Jul 10 14:27 ..                                                                                                                    
drwxr-xr-x    1 gitea    git              8 Jul 10 14:27 git                                                                                                                   
drwxr-xr-x    1 gitea    git             14 Jul 10 14:27 gitea                                                                                                                 
drwx------    1 root     root           312 Jul 10 14:27 ssh 

Why are “git” and “gitea” set to Group:“git” even though this user does not seem to exist:

bash-5.1# id git                                                                                                                                                               
id: unknown user git   

Update:

Ich manually changed the permissions within the container:

bash-5.1# chown -R gitea:users ./data/gitea
bash-5.1# chown -R gitea:users ./data/git

bash-5.1# ls -la ./data/                                                                                                                                                       
total 0                                                                                                                                                                        
dr-xr-x---    1 1026     users           22 Jul 10 14:27 .                                                                                                                     
drwxr-xr-x    1 root     root           148 Jul 10 14:27 ..                                                                                                                    
drwxr-xr-x    1 gitea    users            8 Jul 10 14:27 git                                                                                                                   
drwxr-xr-x    1 gitea    users           14 Jul 10 14:27 gitea                                                                                                                 
drwx------    1 root     root           312 Jul 10 14:27 ssh

on the host machine:

admin@nas:/volume1/testfolder/test1$ ls -la
total 0
drwxrwxrwx+ 1 gitea users  22 Jul 10 16:27 .
drwxrwxrwx+ 1 root  root   22 Jul 10 16:21 ..
drwxr-xr-x  1 gitea users   8 Jul 10 16:27 git
drwxr-xr-x  1 gitea users  14 Jul 10 16:27 gitea
drwx------  1 root root 312 Jul 10 16:27 ssh

I then deleted all permissions within the synology File Station that grant any perms to “Everybody”. Restarted the container afterwards and again the permissions to “Everybody” showed up. I don’t get what’s happening here? Never had that issue with any other docker containers on the Synology…

[dachary]

Here is what I know:

• There are user ids and group ids on the docker host (/etc/group, /etc/password)
• There are user ids and group ids in the gitea docker container (/etc/group, /etc/password)
• The docker daemon is able to do some translation between the two
• Your Synology configures the docker daemon and may or may not influence how this is done

@HansHansen

I then deleted all permissions within the synology File Station that grant any perms to “Everybody”. Restarted the container afterwards and again the permissions to “Everybody” showed up.

This is where Synology maybe does “something” that neither you or me know about. Maybe you could just try to docker run gitea without the help / interference of Synology for diagnostic purposes?

I realize I’m not really helping but hopefully I’m at least as helpful as a rubber duck.

[techknowlogick]

This is what my env vars look like on synology, and the files mounted to disk are the expected UID/GID
FWIW I’m using the rootful image (I run bleeding edge so I use the “:latest” tag, as a maintainer I feel it is my responsibility to run into bugs before others might)

[HansHansen]

@dachary

I realize I’m not really helping but hopefully I’m at least as helpful as a rubber duck .

That’s okay. I really appreciate that you’re trying to help me. Thanks a lot for this.

@techknowlogick: I am also using gitea/gitea:latest.

I tried again with using the default user “git”

on synology:

admin@nas:/volume1/00test$ id git
uid=1043(git) gid=100(users) groups=100(users),65537(docker-users)

admin@nas:/volume1/00test$ ls -la
total 0
drwxrwxrwx+ 1 root root   22 Jul 10 18:05 .
drwxr-xr-x  1 root root  738 Jul 12 14:29 ..
drwxrwxrwx+ 1 root root    8 Jul 12 14:29 @eaDir
drwxrwxrwx+ 1 git  users  22 Jul 12 14:41 gitea

config for gitea/gitea:lastest container:

When i start up the containerthe folder/file read-permissions for the subfolders “gitea” and “git” inside the root mapped folder for gitea are set also for the group “Everyone”,
automatically. Even though i set the full permissions (+rwx for the user specified in the docker setup (“git”, uid: 1043, gid: 100).
Is this behavior (group Everybody) maybe explicitely by design in gitea?

Edit: 4 tried 2 different Synology NAS now (DS216+, DS216+II, DS218, DS718+). All show the same behavoir. (+r permissions automatically set for group “everyone” as soon as the conatainer starts)

[itsgiff]

Did you ever get this resolved? I am running in to the same issues as well.