DEV Community: Sedat Ali Zevit

My Rust TUI Let Any Local User Write to My Terminal

Sedat Ali Zevit — Fri, 02 Oct 2026 15:39:10 +0000

tuxctl is a lightweight, keyboard-first Linux TUI for monitoring and managing processes, systemd services, journal logs, hardware and network activity. It is written in Rust with Ratatui and Crossterm.

While preparing v0.3.0, I found a bug that had been in every earlier release: any local user could make tuxctl write arbitrary bytes to my terminal. No memory corruption, no exploit chain. Just a name in a process list.

This post is about how that happened, how I found it, and why I think it is an easy mistake to make when you build a terminal UI.

The assumption I made

A system monitor reads text from the system and prints it. Process names, command lines and log messages all come from /proc or journalctl, so I treated them as data about the machine: something to measure, sort and lay out in columns.

But much of that text is not written by the system. It is written by whoever can run a process on it. Any local user can set a process name with prctl, choose their own command line, and write a journal message with logger. I was rendering input from the least trusted people on the box, and I never thought of it as input.

Why it happened

When Ratatui renders a span, it removes newline characters and nothing else. The backend then prints each cell's symbol verbatim. So if a process name contains an ESC byte, that byte reaches the terminal as the start of an escape sequence, exactly as if a program had printed it.

Two sequences worried me most:

OSC 52, which asks the terminal to write to the clipboard (in terminals that allow it).
ESC c, which resets the terminal. Rust did not save me here. ESC is a perfectly valid UTF-8 character, so the strings were "safe" as far as the type system was concerned. The problem was never memory safety. It was trusting what the text would do once it was printed.

A harmless demo

You do not need anything dangerous to see the problem. This script gives its own process a name that is an escape sequence setting the terminal window title:

import ctypes, time

libc = ctypes.CDLL(None)
PR_SET_NAME = 15

# ESC ] 0 ; hello BEL  -> "set the window title to hello"
libc.prctl(PR_SET_NAME, b"\x1b]0;hello\x07", 0, 0, 0)
time.sleep(600)

Run it as any user and check /proc/<pid>/comm: the name is stored with the raw escape bytes in it. A monitor that prints that name without cleaning it hands those bytes to your terminal, and the title changes. A title is harmless. The same channel carries the clipboard and reset sequences above, and the person who controls the bytes is not the person looking at the screen.

The same trick works with logger for journal messages and with the command line of any process.

How I found it

I found it in the security review for v0.3.0, not by using the tool. By then the project had 278 automated tests, clean clippy runs, resize sweeps and a performance baseline in CI. None of that caught it, because tests check what you thought to test, and I had never thought of a process name as hostile input.

A note on process: I build tuxctl with Claude as a coding partner, and the pull requests carry Co-Authored-By trailers that say so. The review was part of that workflow, and it was worth it. The question that finds this class of bug is short: which strings on my screen can someone other than me control?

The second bug had the same root cause

The review turned up a second problem. A process whose name is not valid UTF-8 was dropped from the process list, because its /proc/<pid>/stat could not be read as a string. Any user could hide a process from tuxctl by choosing such a name.

It is the same mistake from the other side. In the first bug I trusted the bytes too much when printing them. In the second I assumed the bytes would always be well-formed when reading them. In both cases the data came from someone I do not control.

The fix in v0.3.0

v0.3.0 now removes control characters and bidirectional overrides from everything tuxctl draws. Affected characters are shown as �, so you can still see that something odd was there. The filter covers all drawn text, not only the three sources I knew about when I started looking. Bidirectional overrides are in the list because they can reorder text on screen and make a name look like something it is not.

For the second bug, /proc/<pid>/stat is now read lossily. Processes with non-UTF-8 names appear in the list and can be signaled like any other.

The release added no new dependencies and no async runtime.

What else I checked

Once I was asking "what can a hostile user influence?", I went through the other places where tuxctl touches the system:

Spawned commands. systemctl and journalctl run with fixed arguments. The one sh -c in service.rs is test-only.
Signals. Before sending a signal, tuxctl revalidates the process by (pid, start_time) and sends it through a pidfd, so a recycled PID cannot receive it. Both held up. It was still worth writing them down, because "I checked and it was fine" is a result too.

A checklist if you build a TUI or CLI

List every string you draw that came from outside your program: process names, file names, log lines, hostnames, command output.
Strip control characters and bidirectional overrides before they reach the terminal, at the point where you draw, not in each data source.
Read the rendering library's docs for what it does not sanitize. In my case it removed newlines and nothing more.
Never drop an entry because its text is malformed. Decode lossily and show it, or an attacker can hide things from you.
Test with hostile input on purpose. A passing test suite only covers the cases you imagined. ## If you use tuxctl

Upgrade to v0.3.0 or later, especially if you run it as root or on a shared machine. Prebuilt x86_64 and aarch64 binaries are on the releases page, or build from source:

cargo install --git https://github.com/Seqat/tuxctl --tag v0.3.3 --locked

The code is at github.com/Seqat/tuxctl. If you find another way to make it print something it should not, please open an issue. I would rather hear about it from you than find it in the next review.

Zero backend, zero cost — and three silent bugs I didn't see coming

Sedat Ali Zevit — Sun, 09 Aug 2026 10:12:58 +0000

Every Thursday, Epic gives away a game. Steam runs weekend freebies. Amazon Prime drops a batch that quietly expires two weeks later. Three tabs, three UIs, three different ways of saying "this offer ends soon."

I kept missing claims, so I built OpenClaim — an open-source tracker that aggregates all three, refreshes itself every four hours, and costs exactly nothing to run. No server, no database, no runtime API calls.

The architecture is boring in a good way, and I'll cover it below. But the part worth your time is what happened after it worked: three bugs that produced no errors, no failed builds, and no stack traces. The site kept serving pages. The data was just quietly wrong.

🔗 Live: seqat.github.io/OpenClaim
💻 Source: github.com/Seqat/OpenClaim (MIT)

The architecture, in one paragraph

There is no backend. A GitHub Actions cron job runs a Python pipeline every four hours, which writes a games.json file and commits it to the repo. GitHub Pages serves that file alongside a vanilla ES6 frontend. The browser fetches a same-origin static file — no CORS, no rate limits, no API keys, no cold starts.

GitHub Actions (cron, every 4h)
  ├─ GamerPower REST API  ──┐
  └─ Playwright → Amazon ───┤
                            ▼
                   normalize + dedupe
                            ▼
                      games.json ──▶ committed to repo
                                          ▼
                              GitHub Pages ──▶ browser

My first prototype called the GamerPower API directly from the browser. It worked on localhost and died immediately in production: no Access-Control-Allow-Origin header, and every visitor burning a request against a shared rate limit. Amazon was worse — there's no public API at all.

The fix is a pattern I'd now reach for by default on static hosting: push everything dynamic into the build step, ship the artifact. One scrape serves every visitor. As a bonus, the data ends up version-controlled — git log games.json tells me what was free last month.

Steam and Epic come from GamerPower's REST API, which already aggregates both. I didn't reinvent that. The part I actually had to build is Amazon.

The Amazon scraper, and one trick worth stealing

Amazon Luna / Prime Gaming renders its claims page client-side, so requests returns an empty shell. Playwright handles that. The interesting problem wasn't rendering, it was time: the listing page gives you titles and links, but expiration dates only exist on each game's detail page. Sixteen games meant sixteen extra page loads inside a CI runner.

Three things brought that down to a few seconds. First, five concurrent tabs behind a semaphore. Second, wait_until="domcontentloaded" instead of the default load. Third, the one I hadn't seen elsewhere — blocking assets, but fulfilling CSS instead of aborting it:

await page.route(
    "**/*.{png,jpg,jpeg,webp,svg,css,woff,woff2,gif}",
    lambda route: route.fulfill(status=200, body="", content_type="text/css")
    if ".css" in route.request.url.lower()
    else route.abort()
)

Images, fonts and media get aborted outright. CSS gets served an empty 200 response. The distinction matters: aborting a stylesheet request makes some SPA bundles throw during module loading, and the page never hydrates. An empty stylesheet satisfies the loader while transferring nothing.

Because the page hydrates asynchronously, waiting a fixed duration is either wasteful or flaky, so the scraper polls instead — reading body text every 250ms for up to 3.5 seconds and stopping as soon as a parseable date appears.

For selectors I leaned on attribute substrings (div[class*="Card"], [class*="title"]) rather than exact class names, since the build hashes them. It's more resilient than it looks, and less resilient than I'd like — more on that in a moment.

Bug 1: A ternary with two identical branches

Here's the line that shipped:

is_permanent = True if giveaway_type in ["game", "full game", ""] else True

Read it twice. Both branches return True. Every Steam and Epic entry — 31 of them — was flagged as "permanently free," rendering a ♾️ Permanent badge on the card even when the API had handed me a concrete expiration date sitting right there in the same object.

Nothing failed. No linter complained; it's syntactically fine and the variable is used. The tests didn't catch it because there were no tests. And it was invisible from the outside: a permanent badge on a game that expires next Tuesday looks exactly like a permanent badge on a game that doesn't.

The fix is the whole point of how boring it is:

end_date = parse_iso_date(item.get("end_date"))
is_permanent = end_date is None

The real lesson isn't "read your ternaries." It's that this field was derived state stored as a flag. The moment is_permanent became something you could set independently of end_date, it became something that could disagree with end_date — and nothing in the system was checking that they agreed. The one-line check I now run against generated output would have caught it on day one:

bad = [g for g in games if bool(g["is_permanent"]) != (g.get("end_date") is None)]

Bug 2: A broken scraper publishes an empty site

This one is baked into the architecture I just recommended to you, so it's worth dwelling on.

Both scrapers wrapped their work in a try/except that logged the error and returned an empty list. Reasonable in isolation — one source failing shouldn't take down the other. But main() then did this:

final_games = normalize_and_deduplicate(all_games)
write_json(final_games)   # unconditionally

If Amazon changed a class name, or the runner hit a network hiccup, or GamerPower had a bad minute, the pipeline would cheerfully write an empty games.json, commit it, and push. The job goes green. The site shows zero games. Nothing alerts you, because from CI's perspective everything succeeded — the code ran to completion and produced a file.

This is the failure mode nobody mentions when they tell you to move dynamism into the build step. A server that crashes is loud. A build that succeeds while producing garbage is silent, and it overwrites the last known-good artifact on its way out.

The guard is crude and works:

if not final_games:
    logger.error("No free games fetched. Aborting write to prevent saving empty file.")
    sys.exit(1)

if previous_games and len(final_games) < len(previous_games) * 0.5:
    logger.error(
        f"Sudden drop in free games count (fetched {len(final_games)}, "
        f"previously {len(previous_games)}). Scrapers might be broken. Aborting write."
    )
    sys.exit(1)

Two properties I'd argue are non-negotiable for any commit-the-artifact pipeline:

Failing loudly beats writing quietly. sys.exit(1) turns an invisible data loss into a red X in the Actions tab.
The previous artifact is your baseline. You're committing the output to git, so last run's data is right there. Comparing against it costs nothing and catches partial breakage that an emptiness check misses.

The 50% threshold is arbitrary and I'll probably regret it the first time a legitimately quiet week trips it. That's a better failure than the alternative.

Bug 3: A regex that was too helpful

Amazon writes expiration dates in whatever format it feels like — Available through Sep 23, a localized Turkish string, sometimes a relative in 12 days. So the parser tries patterns in sequence, and the last one was a catch-all:

re.search(r"(\d+)\s*(?:gün|days?)", text)

Applied to page.inner_text("body"). The entire page.

Think about what else lives on an Amazon game page. Review timestamps. Description copy. And, memorably, game titles — 7 Days to Die would have handed that regex a very confident 7, which becomes "expires in 7 days," which becomes a countdown timer on a card, which a user believes.

I deleted the fallback. None is a correct answer; a fabricated date is not. The card renders without a countdown and nobody is misled.

There was a subtler issue in the same code path. Relative dates were computed as now + timedelta(days=n) at scrape time — so a game "expiring in 12 days" got a slightly later timestamp on every four-hour run, drifting forward forever. Pinning to .replace(hour=23, minute=59, second=59) makes the value stable across runs.

The pattern behind all three: in scraping, flexibility is indistinguishable from fabrication. Every fallback you add to "handle more cases" is also a fallback that will confidently produce a wrong answer instead of admitting it doesn't know.

What the deduplication taught me about keys

Minor compared to the above, but it bit in a way I found instructive.

The original dedupe key was a normalized title. Which quietly meant that when a game was free on Steam and Epic in the same week — which happens more than you'd think — one of them silently vanished from the site. The dedupe was working perfectly. The key was just wrong: two entries with the same title on different stores aren't duplicates, they're two different deals a user might want.

norm_title = re.sub(r"[^\w\s]", "", title.casefold())
norm_title = re.sub(r"\s+", " ", norm_title).strip()
norm_key = (platform, norm_title)

Two details in there earned their place. re.sub(r"\s+", " ", ...) because without it "Game Name" and "Game Name" hash apart. And casefold() rather than lower() — the site is bilingual, and Turkish has a dotless ı, so lower() gives you a different string than you expect for titles containing I.

Where it stands

The pipeline runs every four hours, plus two extra attempts on Thursday afternoon to catch Epic's weekly rotation — GitHub's cron is delayed under load often enough that a single scheduled run isn't reliable if you care about a specific moment.

There's a small pytest suite now. Nine tests, which is not many, but they cover the three functions that actually produce data: date parsing, title cleaning, deduplication. One of them exists purely to fail if anyone reintroduces that catch-all regex.

Known rough edges, since you'll find them anyway:

GamerPower returns DLC, playtest access and in-game bundles alongside actual games. They're all technically free offers; they're also noise if you came looking for games. A type filter is the next patch.
The Amazon scraper depends on class-name substrings. It will break. The guard above means it breaks loudly instead of publishing an empty page, which is the best I've got short of a proper contract test.
Tests don't run in CI on pull requests yet.
generated_at changes on every run, so the pipeline commits even when the game list is identical. Six commits a day of pure noise.

If you've run a scraper aggregator for any length of time, I'd genuinely like to know what you did about breakage detection. Health-check endpoints, schema contracts, canary records, or just staring at the Actions tab like I do?

Adding a platform is four steps and documented in CONTRIBUTING.md — drop a file in backend/scrapers/, return a list of dicts matching the schema, register it in main.py. GOG and itch.io are the obvious next ones.

⭐ github.com/Seqat/OpenClaim