6 Commits

Author	SHA1	Message	Date
Chester Fishmans	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: Кот <kot@zeroclaw.local> Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>	2026-10-05 18:47:10 +02:00
Sanaei	892c06c8bc	Bug-label issue sweep: 16 fixes (#6083) ... * fix(xray): block private-range egress in default freedom finalRules (#6037) With domainStrategy AsIs the router never resolves domains, so a domain with a private A record (e.g. 127-0-0-1.nip.io) sails past the geoip:private routing block and freedom's allow-all finalRules let it reach loopback services such as the xray gRPC API and metrics listener. Prepend a block rule for geoip:private to the default template and add the FreedomFinalRulesPrivateEgressBlock seeder so existing installs still carrying the stock allow-only (or legacy private-only-allow) finalRules are upgraded in place; customized rules are left untouched. * fix(sub): version-gate unencrypted-outbound drops in outbound subscriptions (#6033) Commit d38c912d taught CheckXrayConfig to keep unencrypted vless/trojan outbounds when the running core predates the v26.7.11 rejection, but filterOutboundsRejectedByCore still consulted the embedded validator unconditionally, so outbound subscriptions kept silently dropping those outbounds even on downgraded cores. Apply the same shouldSkipLegacyUnencryptedOutboundRejection gate when filtering fetched subscription outbounds. * fix(xray): resolve geodata assets before building outbound configs (#5928) Saving routing or template settings validates each outbound through the embedded config loader, and a freedom outbound whose finalRules reference geoip:private opens geoip.dat during that build. Unlike ApplyRoutingConfig, ValidateOutboundConfig and AddOutbound never pointed the in-process loader at the bin folder, so xray-core resolved the file relative to the panel executable and saving failed with 'stat /usr/local/x-ui/geoip.dat: no such file or directory'. Call ensureXrayAssetLocation before both build paths. * fix(api): use a real i18n key in the client get handler (#5911) The client fetch endpoint localized its error prefix with the bare key 'get', which exists in no translation file, so every lookup of a deleted client's email logged 'message "get" not found in language ...' noise alongside the expected record-not-found warning. Reuse the same pages.inbounds.toasts.obtain key the sibling list handler uses. * fix(sub): carry host record Host header and path into Clash/JSON output (#5944) The raw-link path overrides the host/path share params from a Host record via applyEndpointHostPath, but the Clash and JSON renderers read the transport settings object, which applyHostStreamOverrides never touched — so a Host record's WebSocket Host header (and path) silently vanished from Clash/Mihomo and JSON subscriptions whenever the inbound's own ws settings left them empty. Inject hostHeader/path into the ws/httpupgrade/xhttp settings of the per-host stream, mirroring the raw-link override. * fix(metrics): accept Unicode outbound tags in the observatory (#5972) The observatory validator whitelisted ASCII word characters, so any outbound whose tag carries a flag emoji or other non-ASCII text was silently dropped from the metrics snapshot, delay history, and health notifications. The history store is an in-process map, so the strict charset bought nothing. Validate tags as non-empty, bounded, control-character-free UTF-8 instead, keeping spaces and emoji while still rejecting garbage input on the query path. * fix(database): default sqlite to WAL to stop background-job lock storms (#6057, #6068) With journal_mode=DELETE every write serializes the whole database and blocks readers, so under normal multi-job load (traffic sampling, node sync, mtproto reconcile) transactions regularly outwaited the 10s busy timeout and jobs failed with 'database is locked'. Move to WAL by default: readers no longer block writers and vice versa, which removes the observed contention while writer-writer access still serializes safely. The single-file-at-rest property is preserved where it matters — Checkpoint() now issues wal_checkpoint(TRUNCATE), so panel and Telegram backups read a complete main file, and sqlite folds the WAL back into the db on clean shutdown. XUI_DB_JOURNAL_MODE=DELETE restores the previous behavior for setups that copy the live file directly. * fix(database): strip finalmask.tcp from REALITY inbounds on upgrade (#6038) validateFinalMaskRealityCombo blocks saving finalmask.tcp together with REALITY because that combination crashes Xray-core 26.7.11 on the first connection (XTLS/Xray-core#6453), but it only runs on add/update. An inbound saved before the validator existed sailed through the upgrade untouched and took the core down at boot. Add the InboundRealityFinalmaskTcpStrip seeder: one-time scan that removes finalmask.tcp from REALITY inbounds (other finalmask transports survive), so upgraded panels start cleanly. * fix(xray): stop deleting hand-written direct routing rules on save (#6056) The DNS allow-rule sync recognized 'its' rules purely by shape (type=field, ip, port, outboundTag=direct, nothing else), so any manual rule of that shape — e.g. routing a LAN CIDR to a NAS port over direct — was silently stripped on every settings save. Mark managed rules with ruleTag=xui-dns-allow (round-tripped untouched by both xray-core and the Routing tab editor) and only strip rules that carry the tag. Untagged legacy managed rules are adopted when their exact ip-set/port matches a currently configured private DNS endpoint; anything else is left alone. A stale pre-tag managed rule whose DNS server was removed now lingers until deleted manually — the safe side of the trade against eating user rules. * fix(clients): resolve email lookups through client_inbounds after a move (#6059) GetClientInboundByEmail trusted the client_traffics.inbound_id pointer whenever that inbound still existed, but a client moved between inbounds leaves the row pointing at its old (still existing) inbound. The lookup then searched the wrong inbound's clients and failed with 'Client Not Found In Inbound For Email', which broke the Telegram bot's link and QR generation for moved clients. When the pointed-at inbound no longer carries the email, re-resolve through the authoritative client_inbounds link to the inbound that actually hosts the client. * fix(nodes): replicate inbound fallbacks to nodes (#5963) Fallbacks live in the inbound_fallbacks table and were only merged into settings by the master's local config builder; the runtime inbound pushed to nodes rebuilt settings without them, and the reconcile job additionally fingerprinted the raw DB row, so fallback edits neither reached nodes nor triggered a re-push. Inject settings.fallbacks in buildRuntimeInboundForAPI (mirroring the local builder, gated on inboundCanHostFallbacks) and make ReconcileNode push and fingerprint that same runtime-built payload, aligning the interactive and reconcile paths. * fix(database): survive PostgreSQL outages without a runaway restart loop (#6023) A PostgreSQL that was down or still starting made InitDB fail instantly; the process exited with a generic startup error and systemd restarted it every 5s forever, flooding the journal. Retry the initial postgres connection with backoff (~70s total) and log the real driver error on every attempt, and cap the systemd units with StartLimitIntervalSec/StartLimitBurst so a persistently unreachable database stops the unit instead of looping indefinitely. * fix(xray): force a full restart when REALITY stream settings change (#6010) A changed inbound is normally hot-swapped over gRPC as RemoveInbound + AddInbound, but xray-core does not reliably rebuild a REALITY listener's authenticator on a runtime re-add — key or shortId edits appeared applied yet clients kept authenticating against the old parameters until someone restarted the core manually, on nodes in particular. Treat any non-client change to an inbound that uses (or starts using) REALITY as not hot-appliable so the panel restarts the core instead. Client-only edits on REALITY inbounds keep flowing through the per-user AlterInbound path and still avoid restarts. * feat(sub): allow insecure TLS for outbound subscription fetches (#6067) An outbound subscription served over HTTPS with a self-signed or private-CA certificate could never be fetched: the fetch client had no TLS options, so refreshes died with 'x509: certificate signed by unknown authority' and there was nothing the admin could toggle. Add a per-subscription 'Allow insecure' switch (persisted as allow_insecure, default off) that sets InsecureSkipVerify on the fetch transport — including when the fetch is routed through the panel egress proxy. The SSRF-guarded dialer and redirect re-validation stay in force either way. * fix(reality): send PROXY protocol header in the target scanner when xver is set (#6082) The REALITY target scanner always probed with a plain TLS handshake, so a target fronted by an Nginx listener that requires the PROXY protocol (matching the inbound's xver>=1) reset the connection and the panel reported a false 'TLS handshake failed'. Thread the inbound's xver into the scan request and, when it is >=1, lead with the matching PROXY protocol header (v1 for xver 1, binary v2 for xver 2) built from the dialed connection's own address pair. Batch candidate scans against public sites are unaffected (xver 0). * fix(frontend): default sockopt fields when editing a stored inbound (#5956) Opening an existing inbound ran rawInboundToFormValues over the raw DB row, and only xhttpSettings was re-parsed through its Zod schema to fill defaults. A sockopt object saved before the TProxy control existed has no tproxy key, so the Select rendered blank; picking Off didn't help because the wire normalizer drops tproxy=off, recreating the missing key on the next edit. Re-parse streamSettings.sockopt through SockoptStreamSettingsSchema on load, mirroring the xhttpSettings handling, so absent keys (tproxy, tcpcongestion, …) get their schema defaults every time the form opens.	2026-07-23 15:34:42 +02:00
ssrlive	63a6d40457	Update ExecReload command in x-ui.service.debian (#5219) ... * Update ExecReload command in x-ui.service.debian * fix(systemd): use absolute path in ExecReload for arch and rhel units systemd requires absolute executable paths; kill -USR1 $MAINPID fails with 'Executable path is not absolute'. Matches the debian unit fix. --------- Co-authored-by: MHSanaei <ho3ein.sanaei@gmail.com>	2026-06-12 12:09:48 +02:00
qwardo	e2649f98df	fix(arch): correct x-ui service path (#4213)	2026-05-10 17:17:33 +02:00
Alireza Ahmadi	2b1d3e7347	[feat] restart xray-core from cli #3825	2026-02-20 00:03:16 +01:00
Nebulosa	e6318d57e4	Add x-ui.service.arch file (#3650) ... * Add a service file for Arch-based OSs * Update release.yml with arch service file * Update x-ui.service.arch	2026-01-18 15:41:07 +01:00