Unicode for Usernames

[Otzie2023]

I'd like to start a discussion about the current restriction of usernames to ASCII characters.

Historically, this restriction made sense. It originates from very old POSIX conventions and was intended to maximize compatibility with existing software. However, the question is whether this assumption is still valid in 2026, especially for desktop-oriented Linux distributions.

Linux has evolved significantly over the past 15–20 years. Today, most software is either developed specifically for modern Linux systems or as cross-platform applications where Unicode support is considered standard. At the same time, Unicode has become deeply integrated into nearly every part of the operating system. Filenames, environment variables, terminals, shells, editors, databases, and network services have all handled Unicode reliably for years.

A common argument against Unicode usernames is compatibility with legacy software. But what software are we actually talking about today? Many applications that genuinely only support ASCII are already difficult or impossible to use on modern systems because they depend on outdated libraries or other obsolete components. As a result, the practical risk is likely much smaller than is often assumed.

I can also speak from personal experience. Since 2022, I have been using a username containing non-ASCII characters on Ubuntu (22.04 → 24.04 → 26.04), both on my desktop systems and on a server (Debian12 → Debian13). That server runs Docker containers (Mailcow, OpenMapTiles), Samba, PostgreSQL, and various other services. Over these four years, I have not encountered a single functional or security issue caused by my username. The only problem I experienced was a minor cosmetic issue, which has since been fixed.

Another interesting point is that Linux itself is already technically more capable than many installation wizards suggest. If you create a user from the terminal, Unicode usernames already work without any issues. In many cases, the restriction exists only in graphical installers or setup wizards, not in the operating system itself.

For desktop distributions aimed at end users, relaxing this restriction could improve the overall user experience. Many people are switching to Linux from Windows or macOS, where it is perfectly normal to use names such as "Jörg", "André", "José", "Łukasz", or "Søren" without modification. On Linux, however, users are often forced to alter their names or resort to transliterations like "Joerg" or "Jose". By today's standards, this feels unnecessary and outdated.

I'm not necessarily suggesting that Unicode usernames should be enabled without any safeguards. A reasonable middle ground could be:

• Allow Unicode usernames by default.
• Display a clear warning during installation that very old or poorly maintained software may have compatibility issues.
• Users who require maximum compatibility (for example, in enterprise or legacy environments) can still choose an ASCII-only username.
• For safety, usernames could be restricted to NFC normalization, and a homoglyph filter could be implemented to reduce the risk of visually confusable characters.

This approach would preserve backward compatibility while removing a limitation that, for 99% of desktop users, is likely more theoretical than practical.

Another argument I often hear is that usernames are identifiers and therefore should remain restricted to ASCII.

I don't find this argument particularly convincing. From the operating system's perspective, a username is simply a string associated with a user account. Internally, Linux identifies users by their numeric UID, not by their username. The username primarily serves as a human-readable label mapped to that UID.

From a technical standpoint, it makes little difference to the computer whether a username consists solely of ASCII characters or valid Unicode characters. In both cases, the system ultimately processes a sequence of bytes. Linux has supported Unicode for many years in filenames, paths, environment variables, and numerous other parts of the system, often treating them simply as raw byte sequences. Allowing Unicode in usernames therefore does not introduce a fundamentally new technical challenge.

Moreover, ASCII itself is not free from ambiguity. Usernames such as rn and m, I and l, or O and 0 can already be easily confused by humans. Restricting usernames to ASCII therefore does not eliminate the problem of visually similar identifiers.

For these reasons, I don't find the argument that usernames should remain ASCII-only simply because they are identifiers particularly compelling. The more important question is whether there are still concrete technical or security-related reasons on modern Linux systems that genuinely require such a restriction.

I'm curious to hear what others think. Are there still concrete, reproducible cases where Unicode usernames cause serious problems on modern Linux systems? Or are we simply preserving a historical restriction whose practical value has become increasingly limited?

[Anduin2017]

I totally understand. The only problem is: It's just risky. A lot of users just ignore the warning.

And when some app crashed, they just complain: Junk OS can't run my app.

In the gaming ecosystem, countless Wine prefixes, Steam Proton launch scripts, and even internal engines of older Windows-port games are extremely fragile when parsing non-ASCII paths. Once paths become garbled, games may crash immediately or fail to save. In the development ecosystem, a large number of third-party npm, pip, and even C++ Makefile scripts still rely on legacy regular expressions that only recognize ASCII. While I acknowledge that modern software rarely has these issues, one must remain cautious of quirky apps.

Overall, this change is something you could do, but it unnecessarily adds risk without providing much benefit.

[Otzie2023]

I can certainly understand that, but as you mentioned, this issue is becoming less and less of a problem. So I wouldn’t completely dismiss this idea—I’d keep it in mind for the future, as gaming on Linux continues to mature. Currently, there are already serious discussions about offering official Linux support for some games.
Perhaps the settings menu could be updated first—so that if a user is added later through the settings, it would initially be possible to create usernames with non-ASCII characters there. While that wouldn’t eliminate the problem you described, it would greatly reduce the likelihood of it occurring.

I’d also like to add that older games are currently facing more and more difficulties. For example, because of the Wayland vs. X11 and PulseAudio vs. Piperwire issues. That has caused me more problems than Unicode file paths or Unicode in usernames.
Even all the Angry Birds games from DVDs that run via Wine have no problems with Unicode. Even a smaller game that was originally developed for Windows 2000 and runs via Wine has no problems with it.

What surprises me about Windows is that there are games that might have problems with Unicode file paths. Since Windows NT and XP, Windows has relied entirely on Unicode (UTF-16) internally; this also applies to file paths and usernames. Although UTF-8 and UTF-16 are different, they both use multi-byte sequences that often cause problems. It’s also important to note that NTFS specifies UTF-16LE for filenames, which isn’t compatible with ASCII, and C++ often works directly with bytes. Mixing UTF-16 with ASCII/UTF-8 often leads to visual issues, but I haven’t experienced any complete crashes yet.
So my question is: what does “older ported Windows engines” refer to in terms of time? In other words, which eras of ported Windows engines are being discussed here?

[siyamsec-lab]

I think the compatibility concern is reasonable, especially for a desktop distribution where users may run older games, Wine applications, scripts, or development tools that make assumptions about paths.

That said, I think it would be useful to distinguish between technical impossibility and application compatibility risk. If Linux and the underlying account-management stack can already represent these usernames, then the remaining question is really how much software in the target user base still breaks because of them.

Rather than enabling Unicode usernames everywhere immediately, perhaps AnduinOS could consider a more conservative approach: keep ASCII as the default for the initial user during installation, while allowing Unicode usernames when creating additional accounts through the Settings interface, accompanied by a clear compatibility warning.

That would give users who specifically need Unicode names the option without changing the safest default for most installations.

It would also be interesting to collect concrete examples of applications or games that actually fail with Unicode usernames/paths on current AnduinOS. That could help determine whether this is still a significant practical limitation or primarily a compatibility concern inherited from older software.

[Otzie2023]

I think this approach is a good idea.
@Anduin2017 What do you think?

[Anduin2017]

Thanks for the suggestion. I think my position here is already fairly clear, though, so I’d like to clarify it once more.

I am not arguing that Unicode usernames are technically impossible on modern Linux. They clearly are possible, and I also agree that many modern applications handle them perfectly well.

My concern is simply the risk/reward tradeoff from the distribution maintainer’s perspective.

For AnduinOS, allowing Unicode usernames provides relatively little practical benefit, while it expands the set of possible compatibility problems that I have to support. Even if 99.9% of applications work correctly, the remaining 0.1% matters to me because when some old game, Wine prefix, installer, shell script, enterprise application, or poorly written third-party tool breaks because $HOME contains unexpected characters, the user generally will not blame that application. They will blame the OS.

And ultimately, I am the person who has to investigate those bug reports, explain the issue, document the workaround, and carry the support burden.

That is why I currently prefer the conservative behavior: usernames created through the normal AnduinOS setup flow should remain ASCII-compatible.

Allowing Unicode only for additional users created later does reduce the probability of encountering the issue, but it does not really change the underlying tradeoff. It still introduces another officially supported configuration that can cause unusual compatibility failures, while giving AnduinOS very little benefit in return.

So for now, I don't plan to change this behavior.

This is not a permanent philosophical objection to Unicode usernames. If, in the future, the compatibility risk becomes sufficiently negligible—or there is a strong practical reason for AnduinOS users to need this—I’m happy to reconsider it.

Concrete reproducible examples and ecosystem data are always welcome. But absent a compelling benefit, I would rather keep the safer default than deliberately expand the compatibility surface.