Unable to use symlinks as value for CERT_FILE/KEY_FILE settings

• Gitea version (or commit ref): 1.11.5
• Git version: 2.11.0
• Operating system: Debian 4.9.210-1 x86_64
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • [X ] SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • [X ] Not relevant
• Log gist:

Description

The server has the settings to use HTTPS:

[server]
...
PROTOCOL          = https
ROOT_URL          = https://<My domain>
CERT_FILE         = /etc/letsencrypt/live/<My Path>/fullchain.pem
KEY_FILE          = /etc/letsencrypt/live/<My Path>/privkey.pem

The fullchain.pem is a link to the file /etc/letsencrypt/archive/<My Path>/fullchain3.pem
The privkey.pem is a link to the file /etc/letsencrypt/archive/<My Path>/privkey3.pem

I have got an error:
server.go:107:ListenAndServeTLS() [E] Failed to load https cert file /etc/letsencrypt/live/<My Path>/fullchain.pem for tcp:0.0.0.0:3000: open /etc/letsencrypt/live/<My Path>/fullchain.pem: permission denied

In fact permissions are correct:

Case 1: Error. I have an error "... permission denied."
CERT_FILE = /etc/letsencrypt/live/<My Path>/fullchain.pem
CERT_FILE = /etc/letsencrypt/live/<My Path>/privkey.pem

Case 2: Success. No errors and everything is fine.
CERT_FILE = /etc/letsencrypt/archive/<My Path>/fullchain3.pem
CERT_FILE = /etc/letsencrypt/archive/<My Path>/privkey3.pem

Imo the call ioutil.ReadFile(certFile) is unable to read the symlinks.

[zeripath]

Yup it appears the ioutil.ReadFile returns a os.PathError if the file is symlinked.

Seriously just what is the point of having helpers that don't a) Tell you how they're going to fail b) Don't do the obvious thing of following the damned symlink.

---

This is incorect see: https://play.golang.org/p/16wpSjLjT7X

The error message with permission denied at the end is also incorrect in this case. I think there is a difference between unable to read... (there are many reasons) and ...permission denied (you have to fix the file's permissions).

[zeripath]

The logging is already improved on master if you read the code again.

[zeripath]

Actually it looks like that permission denied is coming directly from the err that is returned from ioutil.ReadFile...

I'm sure there is a function to read file attributes to check link/regular-file. As an example there is Readlink
It might be helpful also: resolve symlinks in Go

[zeripath]

Great there are 20 cases of ioutil.ReadFile.

[zeripath]

See: https://play.golang.org/p/16wpSjLjT7X

ioutil.ReadFile works perfectly fine with symlinks. The problem is genuinely a permissions problem.

Ok. No problem. I will stay with direct paths to .pem-files in my config

[zeripath]

Two things:

• Relative symlinks are often dodgy. I've had issues with dereferencing relative symlinks in multiple situations - they're not always dereferenced from the place you think they are (this affects multiple things not just go). Have you tried with absolute symlinks?
• You have to have permission to read each step along the way to a path. It's no good saying that the file has permission if you cannot read or traverse the directory to it. Is it possible that /etc/letsencrypt/archive or /etc/letsencrypt/archive/xxx do not have correct permissions?

Have you tried with absolute symlinks?

I have a folder structure prepared and supported by script

Is it possible that /etc/letsencrypt/archive or /etc/letsencrypt/archive/xxx do not have correct permissions?

All permissions are correct and nginx is fine with them (just as an example) and it is using the same symlinks.

Again - I'm Ok to stay with direct paths to files. You or I can close the issue.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.