txlyre
synced commits to main at txlyre/3x-ui from mirror
49fbcdc09c fix(frontend): wrap overview modal action buttons on long labels
The Geodata Auto-Update actions row is a non-wrapping flex row with no
gap. Its three buttons fit in English, but the longer Russian, Ukrainian
and Turkish labels make the row wider than the default-width modal, so
the buttons spill out of it. The row now wraps with an 8px gap.
.actions-row is a global class defined identically in VersionModal.css
and PanelUpdateModal.css, so both copies change to keep the cascade
order irrelevant. Verified in Chromium with a temporary Storybook story
rendering VersionModal in ru-RU: the first button sat 88px outside the
modal before the change and inside it after.
Closes #6737
aacfaebab8 fix(tuic): client speed display and certificate button layout (#6723)
* fix(tuic): restore client speed and certificate layout
* docs(tuic): clarify native runtime and protocol behavior
* fix(websocket): preserve traffic updates from independent sources
* fix(docs): sync websocket traffic schema and drop restating TUIC tests
docs/public/openapi.json still described the old traffic event, without
clientTrafficSource/clientTrafficIntervalMs or the TUIC oneOf branch, so
the docs site showed a payload the panel no longer sends. No check
covers that copy.
The TUIC certificate layout test and the TUIC speed payload test only
read back the literals the code writes, so neither could fail on a real
regression. Both are removed, along with the className that existed only
for the layout test.
---------
Co-authored-by: MHSanaei <[email protected]>
e897b0957a fix(sub): append host serverDescription to hysteria links (#6740)
* fix(sub): append host serverDescription to hysteria links
A host's Description reached vless/trojan/ss through buildEndpointLinks, but
genHysteriaLink renders the fragment in its own externalProxy loop and never
added the suffix, so Happ fell back to its "Hysteria | hysteria | TLS" caption
for every Hysteria server on a host that also serves VLESS (#6738).
Reuse appendHappServerDescription with the description the endpoint map already
carries, so no key lookup is duplicated and a host with no description emits the
same bytes as before. genTuicLink (service.go:912) has the same gap; left alone
to keep this diff to the reported protocol.
Regression test is red without the fix for both hysteria:// and hysteria2://.
* chore(sub): trim the hysteria serverDescription regression test
The no-description test passed with and without the #6738 fix: the empty
description branch is already pinned by TestAppendHappServerDescription, so
it certified nothing about this change. Also cut the remaining test's comment
block to the two-line limit CLAUDE.md sets.
---------
Co-authored-by: MHSanaei <[email protected]>
b42a1c0ba1 fix(systemd): harden shipped x-ui unit files (#6718)
* fix(systemd): harden shipped x-ui unit files
The units ran the panel as root with no sandboxing: systemd-analyze
security rates them 9.6 UNSAFE.
Add NoNewPrivileges, ProtectSystem=full with ReadWritePaths for the
default XUI_DB_FOLDER/XUI_BIN_FOLDER/XUI_LOG_FOLDER stores, kernel and
clock protections, UMask=0077, RestrictAddressFamilies, a
CapabilityBoundingSet with NET_ADMIN/NET_BIND_SERVICE/NET_RAW and
SystemCallFilter=@system-service.
PrivateTmp is deliberately omitted: the web updater hands a path inside
the system temp directory to a systemd-run transient unit, which does not
share the service's private tmpfs. ProtectHome stays read-only because
installs keep TLS certificates under the root home directory.
Fixes #6605
* fix(systemd): ship ReadWriteDirectories= alias for systemd < 231
ReadWritePaths= only exists since systemd 231; install.sh still supports
CentOS 7 (systemd 219), where the directive is ignored and ProtectSystem=full
would leave the panel state directory read-only, breaking its database.
* fix(systemd): keep root's DAC bits and regenerate the write paths
Two follow-ups to the hardening, both reported by review on #6718.
CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH were dropped from the bounding set.
Root holds them normally, and a bounding set is subtracted from root too: the
panel could no longer read a private key it does not own (a Caddy-issued
certificate under its own state dir, an acme.sh home, any 0600 file owned by
another account). That fails quietly for TLS -- the panel listener logs the
tls.LoadX509KeyPair error and keeps serving plain HTTP, and Xray inbounds using
that key stop -- so both bits stay.
ProtectSystem=full plus a hard-coded ReadWritePaths list broke installs whose
XUI_DB_FOLDER/XUI_LOG_FOLDER/XUI_BIN_FOLDER live outside the defaults, and the
workaround of editing the unit did not survive an update, because install.sh and
update.sh reinstall the unit from the release tarball. The folders actually in
use are now resolved from the same env file the unit passes to the panel and
regenerated into x-ui.service.d/10-xui-write-paths.conf on every install and
update, so a relocated store stays writable and the list is not reset. The unit
keeps the plain-install defaults plus XUI_SERVICE, which the in-panel updater
needs when systemd-run is unavailable and it falls back to a child process that
inherits this sandbox while update.sh lands the unit again. Uninstall removes
the drop-in with the unit.
* fix(systemd): keep the seccomp whitelist off old systemd, tighten the rest
Review of the previous head found that SystemCallFilter=@system-service plus
SystemCallErrorNumber=EPERM is a hard regression on the platforms this PR means
to keep working. @-named filter groups exist from systemd 239 on, and older
systemd does not ignore an unknown group name: on <231 the name fails to resolve
and the filter stays the built-in whitelist of execve/exit/exit_group/
rt_sigreturn/sigreturn, on 231..238 it degrades to @default. Either way the panel
then gets EPERM on read/openat/mmap/clone and cannot start -- a CentOS 7 or
Ubuntu 18.04 install would come up dead after this update. The two directives now
live in the generated drop-in and are written only when "systemctl --version"
reports 239 or newer, so old hosts keep the rest of the hardening and simply go
without seccomp.
The same review listed three more items, all addressed here:
- a comment claiming ProtectSystem=full "keeps everything outside /var, /run and
the listed ReadWritePaths read-only" -- that is `strict`; `full` locks down
/usr, /boot, /efi and /etc;
- /etc/systemd/system was granted writable for the in-panel updater's fallback,
but that fallback cannot work under this sandbox at all: update.sh also stages
the release archive beside the main folder, replaces /usr/bin/x-ui and calls
the package manager. The entry is gone and update.sh now stops up front with
one clear message when the directories it needs are read-only, instead of
failing halfway with "Failed to download x-ui";
- CAP_DAC_READ_SEARCH is redundant next to CAP_DAC_OVERRIDE, so the bounding set
keeps just the latter.
Relocating a store by editing the env file alone is documented in the unit and
in the generated drop-in: the drop-in is only written by install/update, so one
of those has to be re-run afterwards.
Verified with a local harness (9 checks: plain defaults, relocated store read
from the env file, the same list produced by update.sh, duplicate collapse,
seccomp present at systemd 249 and absent at 238, read-only guard) and bash -n
on install.sh, update.sh, x-ui.sh. systemd-analyze is not available here, so the
unit files themselves are unverified by a parser.
* fix(systemd): actually wire the read-only guard, drop the superseded drop-in
Re-review of the previous head caught two leftovers from that commit:
- require_writable_update_paths was defined but never called, so the guard the
unit comments, the commit message and the PR comment promise did not exist at
all. It is now called at the top level, before install_base, i.e. before
anything with a side effect: a sandboxed fallback run stops with one clear
message instead of failing halfway, which on a relocated main folder meant the
old install removed and the service folder rewritten before dying on /usr/bin.
- the drop-in this branch replaced (10-xui-write-paths.conf) is no longer written
or referenced, but nothing removed it either. Whoever installed the build that
wrote it keeps its wider list, including the writable service folder, until it
is deleted by hand. Both generators now remove it.
Harness extended to 11 checks: the superseded file is gone after a run, the guard
is actually called, plus the previous nine (defaults, env-file relocation, same
list from update.sh, dedupe, seccomp at 249 / absent at 238, read-only guard) and
bash -n on the three scripts.
* fix(systemd): correct two comments and keep spaces out of the path list
Second-opinion review of the previous head (two models, both asked to state
platforms and versions) produced three actionable items: a wrong comment kept
from the earlier commits, a wrong generalisation about the filter groups, and a
path-list case that would leave the panel unable to start.
- the ProtectSystem= comment claimed strict leaves /var and /run writable. It
does not: strict mounts the whole hierarchy read-only and only the kernel API
filesystems stay as they are. The sentence was already wrong before this
branch and moving it to ProtectSystem=full did not fix it.
- "the @-named filter groups need systemd >= 239" is the wrong generalisation:
named groups exist since 231, it is @system-service that arrived in 239. The
unit files, both script comments and the drop-in body now name the group.
- a folder containing whitespace (XUI_DB_FOLDER="/srv/panel data") was written
into ReadWritePaths= verbatim. That directive is a whitespace-separated list,
so the entry splits into "-/srv/panel" and "data", and systemd rejects the
whole drop-in: the panel then does not start at all. Such folders are left
out and reported to the operator instead; the other paths are still written.
Harness extended with three checks for the whitespace case (folder left out,
remaining paths intact, warning emitted) and the duplicate-store case now reads
its own env file instead of the previous one, so it tests what it claims.
14 checks plus bash -n on the three scripts, all passing.
* fix(systemd): act on the independent review of the drop-in generator
A read-only review of the branch head (another model, given the diff and the
sources, asked to cite only verified lines) confirmed the earlier work and
turned up four items that are fixed here:
- a folder name carrying a literal % went into ReadWritePaths= as it was, and
systemd expands %-specifiers in unit files: with XUI_DB_FOLDER=/srv/x%-ui the
entry no longer named the directory the panel writes to and the panel could
not write its database. The path is now emitted as %%; the duplicate check
keeps comparing the unescaped value.
- systemd older than 229/242/244 does not know NoNewPrivileges, ProtectClock,
ProtectHostname and ProtectKernelLogs. It logs them and carries on, so
CentOS 7 (systemd 219, which install.sh explicitly supports) runs with less
hardening than the unit lists. install.sh and update.sh now print which
protections need a newer systemd, which ones still apply, and that upgrading
systemd is what changes it.
- the updater's writability guard asked [[ -w ]] about the parent directories.
It creates and removes a probe file instead, so an immutable attribute or a
full filesystem is caught as well (a read-only mount was already caught).
- the generator's comment claimed to resolve the folders the service actually
uses, while the shipped unit hard-codes WorkingDirectory= and ExecStart= under
/usr/local/x-ui. The comment now states what XUI_MAIN_FOLDER really feeds --
the location install.sh/update.sh install into and the base for a relative
XUI_BIN_FOLDER -- and that a relocated main folder needs the unit edited too.
Rejected from the same review, with the evidence: that [[ -w ]] cannot see a
read-only mount (access(W_OK)/faccessat consults __mnt_is_readonly before the
mode bits), and that the /etc ReadWritePaths entry is an exception granted for
/etc rather than a default store already in the list.
Harness extended: 19 checks (escaped %, the old-systemd note, whitespace and
duplicate folders, seccomp gating, the read-only guard) plus bash -n on the
three scripts, all passing.
* fix(systemd): name the hardening old systemd really ignores
The old-systemd note fired only below 239 and listed wrong versions:
RHEL 8 (239) and Debian 10 (241) silently lose ProtectHostname and
RestrictSUIDSGID (242), ProtectKernelLogs (244) and ProtectClock (245)
with no note, while CentOS 7 was told NoNewPrivileges (187) and
ProtectHome=read-only (214) were not applied although both are. The
note is now built from a directive/version table taken from
systemd.exec(5) and lists only what the running systemd lacks.
Also drop the removal of 10-xui-write-paths.conf: only an intermediate
commit of this branch wrote that file, no release ever shipped it.
---------
Co-authored-by: Кот <[email protected]>
Co-authored-by: Sanaei <[email protected]>
a8d65a55b0 fix(update): run the database migration before starting the service (#6729)
update_x-ui() started x-ui.service and then called config_after_update right
away, which runs `x-ui setting -show true` and `x-ui migrate`. The service and
the CLI each run InitDB(), and with it every schema migration, on the same
database at the same time. On an upgrade that adds schema, the loser exits
with an error. Upgrading 3.8.5 to 3.9.0 stopped the service with
"duplicate column name: exclude_from_sub", and only Restart=on-failure
brought it back 5 s later.
Tolerating the duplicate-column error in the column helpers is not enough.
The same race also hits the tables new in 3.9.0: concurrent InitDB fails with
"table `node_pending_resets` already exists" and
"table `tuic_traffic_receipts` already exists". The cause is two processes
migrating at once, so the fix is to stop that from happening during update.
Run `x-ui migrate` to completion before the service is started, on both the
systemd and the OpenRC path. This mirrors install.sh, whose
config_after_install already migrates before the first start. The service and
the follow-up CLI calls then find the schema current, and their InitDB has
nothing to change.
Refs #6728
- View comparison for these 9 commits »
2 days ago