Can't use ACL to allow access by other users #9025

New Issue

GiteaMirror · 2025-11-02T08:26:18-06:00

GiteaMirror commented

2025-11-02 08:26:18 -06:00

Originally created by @hgaiser on GitHub (Jun 4, 2022).

Description

I would like to allow access of the files created by gitea for a user specific user on my system. I'm using that user to backup my gitea files to another location. However, if I allow access by using ACL, then SSH access is broken until I restart gitea (which seems to undo the ACL modifications).

I run:

setfacl -R -m u:automation:r-X /var/lib/gitea
setfacl -R -d -m u:automation:r-X /var/libgitea

If I then try to clone a repository I get:

git clone git@hostname:hgaiser/repository
Cloning into 'repository'...
kex_exchange_identification: Connection closed by remote host
Connection closed by 127.0.0.1 port 2222
fatal: Could not read from remote repository.

Please make sure you have the correct access rights

In my logs I see a few times:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for '/data/ssh/ssh_host_ecdsa_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Unable to load host key "/data/ssh/ssh_host_ecdsa_key": bad permissions
Unable to load host key: /data/ssh/ssh_host_ecdsa_key

Which strikes me as a bit weird, because if I check the permissions on that file with getfacl ssh_host_ecdsa_key I see:

# file: ssh_host_ecdsa_key
# owner: root
# group: root
user::rw-
user:automation:r--
group::---
mask::r--
other::---

Which would mean that no one from that group has permissions, so it should be 0600, not 0640.

If I restart gitea, the permissions are automatically fixed, meaning I have ssh access again, but I can't use my automation user to perform backups.

Am I doing something wrong in this process, or is gitea handling these ACL rights in an unexpected way?

Gitea Version

1.16.8

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Arch Linux

How are you running Gitea?

I'm running gitea using the docker image provided here.

Database

PostgreSQL

Originally created by @hgaiser on GitHub (Jun 4, 2022). ### Description I would like to allow access of the files created by gitea for a user specific user on my system. I'm using that user to backup my gitea files to another location. However, if I allow access by using [ACL](https://www.redhat.com/sysadmin/linux-access-control-lists), then SSH access is broken until I restart gitea (which seems to undo the ACL modifications). I run: ```sh setfacl -R -m u:automation:r-X /var/lib/gitea setfacl -R -d -m u:automation:r-X /var/libgitea ``` If I then try to clone a repository I get: ``` git clone git@hostname:hgaiser/repository Cloning into 'repository'... kex_exchange_identification: Connection closed by remote host Connection closed by 127.0.0.1 port 2222 fatal: Could not read from remote repository. Please make sure you have the correct access rights ``` In my logs I see a few times: ``` @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0640 for '/data/ssh/ssh_host_ecdsa_key' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Unable to load host key "/data/ssh/ssh_host_ecdsa_key": bad permissions Unable to load host key: /data/ssh/ssh_host_ecdsa_key ``` Which strikes me as a bit weird, because if I check the permissions on that file with `getfacl ssh_host_ecdsa_key` I see: ``` # file: ssh_host_ecdsa_key # owner: root # group: root user::rw- user:automation:r-- group::--- mask::r-- other::--- ``` Which would mean that no one from that group has permissions, so it should be 0600, not 0640. If I restart gitea, the permissions are automatically fixed, meaning I have ssh access again, but I can't use my `automation` user to perform backups. Am I doing something wrong in this process, or is gitea handling these ACL rights in an unexpected way? ### Gitea Version 1.16.8 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System Arch Linux ### How are you running Gitea? I'm running gitea using the docker image provided [here](https://hub.docker.com/r/gitea/gitea). ### Database PostgreSQL

GiteaMirror added the type/bug label 2025-11-02 08:26:18 -06:00

GiteaMirror closed this issue

2025-11-02 08:26:18 -06:00

GiteaMirror commented

2025-11-02 08:26:19 -06:00

@zeripath commented on GitHub (Jun 4, 2022):

https://unix.stackexchange.com/questions/65888/setfacl-incorrectly-changes-group-permissions

@zeripath commented on GitHub (Jun 4, 2022): https://unix.stackexchange.com/questions/65888/setfacl-incorrectly-changes-group-permissions

GiteaMirror commented

2025-11-02 08:26:19 -06:00

@zeripath commented on GitHub (Jun 4, 2022):

man acl 5

CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS
     The permissions defined by ACLs are a superset of the permissions specified by the file permis‐
     sion bits.

     There is a correspondence between the file owner, group, and other permissions and specific ACL
     entries: the owner permissions correspond to the permissions of the ACL_USER_OBJ entry. If the
     ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK
     entry.  Otherwise, if the ACL has no ACL_MASK entry, the group permissions correspond to the per‐
     missions of the ACL_GROUP_OBJ entry.  The other permissions correspond to the permissions of the
     ACL_OTHER entry.

     The file owner, group, and other permissions always match the permissions of the corresponding
     ACL entry. Modification of the file permission bits results in the modification of the associated
     ACL entries, and modification of these ACL entries results in the modification of the file per‐
     mission bits.

@zeripath commented on GitHub (Jun 4, 2022): `man acl 5` ``` CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS The permissions defined by ACLs are a superset of the permissions specified by the file permis‐ sion bits. There is a correspondence between the file owner, group, and other permissions and specific ACL entries: the owner permissions correspond to the permissions of the ACL_USER_OBJ entry. If the ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK entry. Otherwise, if the ACL has no ACL_MASK entry, the group permissions correspond to the per‐ missions of the ACL_GROUP_OBJ entry. The other permissions correspond to the permissions of the ACL_OTHER entry. The file owner, group, and other permissions always match the permissions of the corresponding ACL entry. Modification of the file permission bits results in the modification of the associated ACL entries, and modification of these ACL entries results in the modification of the file per‐ mission bits. ```

GiteaMirror commented

2025-11-02 08:26:19 -06:00

@hgaiser commented on GitHub (Jun 4, 2022):

Thanks for your response @zeripath , I had assumed this was a gitea issue, but I see now that it is a deeper issue with file permissions and the permissions that ssh requires.

Do you have any suggestions to achieve what I'm trying to do (create backups of gitea data)? I've seen suggestions along the lines of running the backup as root, or adding capabilities to the automation user. Both would grant too much permissions to the automation user, I prefer to give that user only the required permissions and nothing more.

That said, seems this is not a gitea issue so I'll go ahead and close it.

I'm curious to hear your suggestions.

@hgaiser commented on GitHub (Jun 4, 2022): Thanks for your response @zeripath , I had assumed this was a gitea issue, but I see now that it is a deeper issue with file permissions and the permissions that ssh requires. Do you have any suggestions to achieve what I'm trying to do (create backups of gitea data)? I've seen suggestions along the lines of running the backup as root, or adding capabilities to the automation user. Both would grant too much permissions to the automation user, I prefer to give that user only the required permissions and nothing more. That said, seems this is not a gitea issue so I'll go ahead and close it. I'm curious to hear your suggestions.

GiteaMirror commented

2025-11-02 08:26:20 -06:00

@zeripath commented on GitHub (Jun 4, 2022):

You could use an authorized keys command for SSH instead of using .ssh/authorized_keys.

Or you could just avoid backing up the .ssh folder as the authorized_keys file will be auto generated on startup of Gitea in any case.

@zeripath commented on GitHub (Jun 4, 2022): You could use an authorized keys command for SSH instead of using .ssh/authorized_keys. Or you could just avoid backing up the .ssh folder as the authorized_keys file will be auto generated on startup of Gitea in any case.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9025