When was the famous "sudo warning" introduced? (2019)

Historical context of the sudo warning

  • The classic sudo “lecture” and the “This incident will be reported” message are seen as cultural artifacts from multi‑user Unix times, similar in spirit to old “unauthorized access is prohibited” login banners.
  • Some remember local variants or jokes replacing it, and note that messages like this can acquire a life of their own as memorable “mind viruses.”

Sudo, passwords, and usability

  • Several argue that requiring passwords for routine desktop tasks (e.g., installing apps) is outdated friction, especially on single‑user laptops where the same person is both “user” and “admin.”
  • Others defend password prompts as a reasonable security checkpoint and a moment for users to reconsider granting elevated rights.
  • It’s noted that sudo can be configured to skip passwords (e.g., NOPASSWD) or tuned, and that polkit/biometrics or app‑store‑style models change the UX but bring their own complexity.

Single‑user reality vs multi‑user heritage

  • Many point out that modern Linux use is often single‑user (laptops, phones), making traditional user/root separation feel anachronistic.
  • Others counter that multi‑user remains important in HPC, universities, and fleets of servers, where sudo plus per‑user logins provide auditability and safer operations than direct root logins.

Privilege models, containers, and multitenancy

  • Debate over whether user accounts should still be a core security boundary or replaced by per‑application isolation and stronger kernel‑level multitenancy.
  • Some argue Linux’s model is “lacking” for running untrusted workloads at scale; others say root+users has been standard long before Linux and is not inherently deficient.
  • Containers, VMs, gVisor, and serverless are discussed as partial workarounds, with concerns about DoS, fairness, and overhead.

Per‑app isolation and sandboxing

  • Several express desire for per‑application sandboxes so each app sees only a minimal subset of $HOME.
  • Various tools are mentioned: Flatpak, Snap, systemd‑nspawn, firejail, OpenBSD’s unveil/pledge, Distrobox, immutable distros, and systemd’s DynamicUser; trade‑offs include complexity, security guarantees, and app availability.

Legal warnings and login banners

  • Old advice to add explicit “unauthorized access prohibited” text at login is compared to sudo’s warning and to boilerplate email disclaimers.
  • Some see these as mostly legal theater; others note certain standards and regulations explicitly require such notices.