cloudflared service improvements
#1
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Cloudflared
crinklywrappr
changed the title
cloudflared service improvemntscloudflared service improvements
bbigras
force-pushed
the
cloudflared
branch
2 times, most recently
from
0db9c4f to
c770b44
Compare
bbigras
pushed a commit
that referenced
this pull request
Aug 28, 2024
Strongly inspired by the forgejo counterpart[1], for the following
reasons:
* The feature is broken with the current module and crashes on
authentication with the following stacktrace (with a PAM service
`gitea` added):
server # Stack trace of thread 1008:
server # #0 0x00007f3116917dfb __nptl_setxid (libc.so.6 + 0x8ddfb)
server # #1 0x00007f3116980ae6 setuid (libc.so.6 + 0xf6ae6)
server # NixOS#2 0x00007f30cc80f420 _unix_run_helper_binary (pam_unix.so + 0x5420)
server # NixOS#3 0x00007f30cc8108c9 _unix_verify_password (pam_unix.so + 0x68c9)
server # NixOS#4 0x00007f30cc80e1b5 pam_sm_authenticate (pam_unix.so + 0x41b5)
server # NixOS#5 0x00007f3116a84e5b _pam_dispatch (libpam.so.0 + 0x3e5b)
server # NixOS#6 0x00007f3116a846a3 pam_authenticate (libpam.so.0 + 0x36a3)
server # NixOS#7 0x00000000029b1e7a n/a (.gitea-wrapped + 0x25b1e7a)
server # NixOS#8 0x000000000047c7e4 n/a (.gitea-wrapped + 0x7c7e4)
server # ELF object binary architecture: AMD x86-64
server #
server # [ 42.420827] gitea[897]: pam_unix(gitea:auth): unix_chkpwd abnormal exit: 159
server # [ 42.423142] gitea[897]: pam_unix(gitea:auth): authentication failure; logname= uid=998 euid=998 tty= ruser= rhost= user=snenskek
It only worked after turning off multiple sandbox settings and adding
`shadow` as supplementary group to `gitea.service`.
I'm not willing to maintain additional multiple sandbox settings for
different features, especially given that it was probably not used for
quite a long time:
* There was no PR or bugreport about sandboxing issues related to
PAM.
* Ever since the module exists, it used the user `gitea`, i.e. it had
never read-access to `/etc/shadow`.
* Upstream has it disabled by default[2].
If somebody really needs it, it can still be brought back by an overlay
updating `tags` accordingly and modifying the systemd service config.
[1] 07641a9
[2] https://docs.gitea.com/usage/authentication#pam-pluggable-authentication-module
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
originCert
I found that
cloudflaredsometimes wanted access to the original certificate during testing, so I added a nullableoriginCertoption. Looking at it now, it probably needs amkIf (tunnel.originCert != null)in the configuration definition. I'll come back to that if you think it's necessary.credentialsFile
types.pathsuites it better.warp-routing.enabled
false, since it's going into the file regardless of the value.default ingress
Default to HTTP status 404. One less thing to spell out in the system configuration.
add cloudflared as a system package
Many other services do this.
refine the systemd service unit
RestartSecsetting, since it restarted too quickly to be useful during testing w/ a failing tunnel.warp-svcto theafterrule b/c of thewarp-routing.enabledoption. This is based on the work @WolfangAukang is doing in this PR.