I
Weil ich heute Jammer in einer Zeitung las, daß in einer Schule nicht mehr verwendbare iPads verschrottet werden, statt sie einer Zweiverwendung zuzu führen.
Muß man halt die Arbeit leisten, die Dinger korrekt zu managen, und das gilt auch für das Ende des Lifecycles.
Ihr seid wahrscheinlich wie ich mit PCs groß geworden und habt deshalb ein bestimmtes Bild davon, was ein „Computer“ ist: CPU im Sockel, RAM-Riegel, Steckkarten, Laufwerke, Kabel. Man konnte Dinge austauschen, erweitern, reparieren. Der Rechner bestand aus einzelnen Komponenten.
So funktionieren Computer heute nicht mehr.
Moderne Rechner bestehen aus einem hochintegrierten SoC oder Multi-Die-Package, in dem CPU, GPU, RAM, Speichercontroller, Medienencoder, AI-Beschleuniger und große Teile des I/O-Subsystems gemeinsam sitzen. Ein moderner Mac ist architektonisch näher an einem Smartphone ohne Akku und mit besserer Kühlung als an einem klassischen Tower-PC.
Deshalb gibt es keine CPU-Sockel, keine RAM-Slots und kaum noch diskrete Komponenten. Das ist kein böser Wille, sondern der Preis für Leistung, Energieeffizienz, Speicherbandbreite und niedrige Latenzen. (Mail Lesen mit dem Tower: 150W; mit dem Mini: 5W; mit dem iPhone: 0.5W)
Dadurch gehen Rechner heute tatsächlich seltener kaputt als früher. Wenn aber etwas kaputtgeht, tauscht man nicht mehr einzelne PC-Komponenten, sondern ganze Baugruppen wie Logic Board, Display oder Batterie, weil der eigentliche „Computer“ kein Baukasten mehr ist, sondern ein integriertes System.
Hersteller wie Apple stellen außerdem Sicherheit und Diebstahlschutz in den Vordergrund, besonders im Enterprise-Umfeld.
Geräte sind heute oft bereits beim Hersteller einer Organisation zugeordnet. Sobald ein Rechner installiert wird, meldet er sich beim Hersteller, erhält automatisch das Firmen-MDM und installiert die Unternehmenssoftware selbstständig. Ein gestohlenes Gerät wird dadurch praktisch wertlos.
Dasselbe gilt für Einzelteile. Batterie, Display, Kamera, Tastatur und andere Komponenten haben eigene Seriennummern und sind dem Gerät zugeordnet. Austausch mit gestohlenen oder nicht autorisierten Teilen kann erkannt und markiert werden.
Das macht Gebrauchtverkauf und Reparatur komplizierter. Ein Gerät kann nicht mehr einfach gegen Bargeld den Besitzer wechseln, sondern muss sauber deregistriert und freigegeben werden. Gleichzeitig sorgt genau das dafür, dass Unternehmensdaten zuverlässig entfernt werden und Geräte GDPR-konform aus dem Bestand fallen.
Das verhindert Reparaturen mit Diebstahlware, erschwert Hehlerei und macht den spontanen Weiterverkauf unbequemer. Ich halte das für ein Feature, nicht für einen Fehler.
@barubary You do not read a directory race-free in the snapshot sense.
A directory fd gives you a stable ref to THAT directory object, not a stable list of its children.
You CAN do
dirfd = openat2(parentfd, "subdir", ...);
getdents64(dirfd, ...); // or fdopendir/readdir
openat(dirfd, name, ...); // act relative to the same directory
That avoids races involving CWD, replaced parent paths, symlinked path components, and “I checked one path but opened another”.
The entries themselves can still change while you read. Another process can create, delete, rename, or replace name after readdir() returns it and before openat() uses it. Linux does not make readdir() a frozen transaction. A directory fd pins the directory, not its contents.
So you'd
For recursive traversal, you extend the same rule: open child directories with openat() or openat2(), reject symlinks with flags/resolution constraints, keep dirfds on a stack, and perform later operations relative to those dirfds.
The oss-sec report’s uutils examples are mostly failures of this kind: path-based second operations, permission changes after creation, missing O_NOFOLLOW, missing O_EXCL, or creating too broadly and tightening later.
A truly race-free directory listing would mean one of three things:
None of that is desireable, because it will scale like shit.
A snapshot is desirable for backups, indexing, forensics, package database consistency, and reproducible tree copies. But then the right answer is usually “use a filesystem snapshot”, not “make readdir() magic”.
What we do need is a Linux-centric update to W. Richard Stevens of APUE, an APLE book.
It would be discussing working with the Linux kernel API correctly, maybe implementing a libc or a libc-replacement, or a Python or Rust kernel API interface, correctly, with error handling, using code.
Stevens had a wonderful writing style, in English and in Code, showcasing the point made in a chapter without compromising on correctness and production-ready error handling.
But his books and the API he describes are old, and from the Linux Kernel PoV also inferior and outdated.
@hllizi See followup post: This has largely alread happened (improving the kernel fd API).
File naming has been decoupled from the API that does things with files through these fd-based calls. So once you have an fd you should be set.
But:
Linux at the upper kernel layer does not change POSIX filename requirements. Filenames can be random garbage as long as they do not contain pathsep (the slash) and Nullbytes.
There is no clean, portable Linux syscall that says: “this directory accepts exactly UTF-8” or “this directory accepts arbitrary bytes.” The safe model is still: treat filenames as byte strings, not text, until you must display or create human-facing names.
That means your programming language must work with byte-arrays as filenames, even when that seems to be silly.
Linux pathname rules are byte-oriented: a pathname is a null-terminated byte sequence, interior null bytes are forbidden, and / is the separator, not a filename byte.
Directory reads likewise return null-terminated d_name entries, not Unicode strings.
For creating new human-facing filenames, emit valid UTF-8, preferably normalized to NFC at the application layer. But still be prepared for EINVAL, ENAMETOOLONG, EEXIST, or filesystem-specific rejection – some filesystems have magic filenames such as nul, prn or con and you won't be able to use them.
For accepting existing names, accept arbitrary bytes except / and \0. A UTF-8-only application that refuses to operate on invalid names will break on normal Unix trees, backups, tar extractions, old mounts, removable media, and network filesystems.
For detecting constraints, the options are weak:
statfs() tells you the filesystem type, so you can special-case ext4, vfat, ntfs3, btrfs, overlayfs, etc., but that is not a semantic contract. You will need to know the rules for each filesystem type, there is no way to query them.
pathconf(path, _PC_NAME_MAX) tells you name length limits, not encoding.
statx() gives richer file metadata, but not a general filename-encoding capability, and surely not lists of reserved names or other fancyness.
Some filesystems have feature-specific behavior. ext4 casefolding, for example, stores a filesystem-wide encoding model for case-insensitive directories, defaulting to UTF-8 in the kernel documentation. That does not turn Linux pathname handling generally into Unicode.
So we DO have an API that could be race-free if you used to fully, and in order to do that you'd use Linux specific syscalls.
We LACK an API that can handle structured filenames, and answer questions about naming restrictions properly.
There is no
query_name_policy(dirfd) → accepted encoding, normalization rules, case-sensitivity/case-folding, max component length in bytes and characters, reserved names, forbidden code points/bytes, equivalence rules, stable display form, and whether invalid legacy names may already exist.
Part of that work is already done.
Linux’s syscall surface has a pattern: take a narrow primitive, remove implicit global state, make it composable, and push work into the kernel to avoid copies or races. clone(), openat(), and splice() fit that pattern well.
There are several other clusters of similar “upgrades”.
First, the at family generalizes path-based syscalls to operate relative to a directory file descriptor, which eliminates reliance on the process-wide CWD and closes race windows.
Besides openat(), there are fstatat(), linkat(), renameat(), unlinkat(), mkdirat(), symlinkat(), and more recently openat2() with a struct-based argument that lets you constrain resolution (no symlinks, stay beneath a dir, etc.).
POSIX standardized a subset of this idea in POSIX.1-2008: the basic *at() calls exist there, but Linux-specific extensions like openat2() and its resolution flags are not in POSIX.
Second, file-descriptor–centric design is pushed much further than POSIX.
Linux prefers operations that take FDs instead of paths and adds syscalls to obtain stable references: O_PATH, name_to_handle_at() and open_by_handle_at() (exportable file handles), pidfd_open() and the broader pidfd API for race-free process management, and memfd_create() for anonymous in-kernel files.
POSIX largely sticks to PIDs and pathnames; pidfds, memfd, and file handles are Linux-only.
Third, race-free event and I/O multiplexing. Linux moved from select()/poll() to epoll (edge-triggered, scalable readiness notification) and then to io_uring, which is a much bigger step: shared submission/completion queues, batching, fixed buffers/files, and true async operations with fewer syscalls.
POSIX includes select() and poll(), and optionally AIO (aio_*), but epoll and io_uring are Linux-specific.
Fourth, zero-copy and in-kernel data movement. Beyond sendfile() → splice(), there’s tee() (duplicate a pipe buffer without copying) and vmsplice() (map user pages into a pipe).
These let you build pipelines where data stays in kernel space. POSIX has sendfile() only via non-standard extensions on some systems; splice/tee/vmsplice are not in POSIX.
Fifth, vector and message-oriented batching. readv()/writev() exist in POSIX, but Linux extends batching with preadv2()/pwritev2() flags, recvmmsg()/sendmmsg() to amortize syscall overhead for datagrams, and various flags for finer control.
The mmsg calls are Linux-specific.
Sixth, futexes for user-space synchronization. futex() lets user space do uncontended locking without syscalls and only enter the kernel on contention.
This is the basis for efficient pthread mutexes/condvars on Linux.
POSIX defines the pthread APIs, not the futex primitive; futex is Linux-specific.
Seventh, namespaces and capabilities. Syscalls like unshare(), setns(), and clone() flags create per-process views of resources (mount, PID, net, user namespaces).
This is foundational for containers.
POSIX has no concept of namespaces or Linux capabilities.
Eighth, timers, event FDs, and signal improvements. timerfd_create(), eventfd(), and signalfd() turn timers, counters, and signals into file descriptors that integrate with epoll.
POSIX has timers and signals, but not these FD-based forms.
Ninth, process creation refinement. clone3() is a modern, extensible variant of clone() with a struct argument, similar in spirit to openat2().
POSIX sticks with fork() and posix_spawn(); clone* is Linux-specific.
Tenth, memory management extensions. mremap(), madvise() flags beyond POSIX, userfaultfd() (handle page faults in user space), memfd_secret (restricted mappings).
POSIX defines mmap()/mprotect()/msync(); the rest are Linux extensions.
Eleventh, mount API overhaul. The newer mount API (open_tree(), move_mount(), fsopen(), fsconfig(), fsmount()) replaces the legacy mount() string interface with FD-based, race-resistant operations.
This is Linux-only.
Twelfth, BPF as a syscall-backed subsystem. The bpf() syscall exposes a programmable kernel data path and observability tools.
Entirely Linux-specific.
On POSIX coverage, the pattern is consistent: when Linux introduces a generalization that reduces races and global state in a way that’s broadly portable, a conservative subset may eventually appear in POSIX (the *at() family, readv/writev, posix_spawn). The more ambitious pieces that depend on Linux’s internal models or aim at performance and containerization (epoll, io_uring, pidfds, namespaces, futex, BPF, new mount API, zero-copy pipe primitives) are not in POSIX and are unlikely to be standardized in their current form.
@iwein I don't care much. If the Linux kernel does it, the rest will eventually follow. Or not, but they are sidelined already anyway, so who cares.
RE: https://infosec.exchange/@lcamtuf/116517194178120536
"Hahaha, look at how Rust failed here."
Maybe writing a utility like cp without TOCTOU, race conditions, symlink exploits and the like shouldn't be hard. Maybe copying a file shouldn't require more than a single line in userspace.
Maybe the UNIX file API is incomplete and could do with a number of revisions and updates. Maybe, after 40, 50 years we have learned a few things and should go through it with a fine comb.
Of course we shouldn't break userspace. We can still provide the old, broken calls.
But maybe we should discuss how we can come up with something systematic that doesn't suck and invite these kinds of bugs. In any language.
https://www.tagesschau.de/ausland/asien/vae-austritt-opec-folgen-100.html
Es wirkt sich kurzfristig nicht groß auf die Märkte aus, weil die Straße von Hormus geschlossen ist. Aber in Zukunft, wenn sich der Export normalisiert hat, könnten die VAE viele Barrels ohne Restriktionen auf den Markt bringen.
Das ist ja auch eine grenzenlose Naivität über die Zukunft die da am Werken ist.
Dude, hast Du Asien im Blick?
Das Öl wird noch in Deutschland gekauft und für Kunststoff. Aber als Erdöl Exporteur oder Tanker Besitzer würde ich mich umorientieren wollen, stat
That is actually quite nonsense.
There are a bunch of vehicles classifed as Pedelec that have three or four wheels and are safe from falling.
Speed of bikes is low enough to accomodate people with slower reaction time, and partially impaired senses.
Energies are so much lower that it is now longer funny, 1/16th of the energy from speed (100 km/h -> 25 km/h), and that is generous. 1/10th the energy from mass (1000 kg -> 100 kg), again that is generous, so at least 160x less energy in any collision, likely less than 250x less energy.
The failure is to put these vehicles into a car environment, that is always deadly. But that can be remedied, look to NL to how to do it.
If you were a customer of Interrail, maybe also buy a car?
Deutsche Version hinter dem Trennstrich
===
Dear Customer,
we are writing to confirm that the situation has, in fact, developed exactly as badly as you suspected after our previous message about a security incident. With this message we want to update you about important recent developments.
What has happened?
We informed you that, as a result of a security incident caused by our enthusiastic commitment to shipping fast and thinking later, your personal data migrated from our database to one operated by people with stronger incentives and better tooling.
Following that discovery, we immediately began the work to secure our legal position and reluctantly also secure our system. We initiated an investigation what that code actually does, and it does not look good.
We can now confirm that the following categories of your personal data are being actively circulated, monetized, and repurposed by actors who face even fewer internal constraints than we do:
We understand this may cause concern. Statistically, that concern is justified.
Our legal advisors tell us to advise you to change your password, your passport, your phone number, your email provider, your gender, your name and your country of residence.
We take the security of your data seriously (*1) and will continue to do so in all future communications on this topic.
Good luck and godspeed.
(*1) This statement is legally required and should not be interpreted as evidence. “Seriously” in this context refers to tone, not outcome.
===
Sehr geehrte Kundin, sehr geehrter Kunde,
wir melden uns, um zu bestätigen, was Sie nach unserer letzten Nachricht zu dem Sicherheitsvorfall ohnehin schon vermutet haben: Es ist tatsächlich genau so schlimm geworden.
Was ist passiert?
Wie bereits angekündigt, hat ein Sicherheitsvorfall dazu geführt, dass Ihre personenbezogenen Daten unsere Systeme verlassen haben. Auslöser war unser bewährter Ansatz, erst schnell zu liefern und anschließend zu überlegen. Ihre Daten befinden sich nun in einer Umgebung, die von Personen betrieben wird, die über bessere Werkzeuge verfügen und deutlich stärkere Anreize haben, diese auch zu nutzen.
Nach dieser Erkenntnis haben wir umgehend Maßnahmen ergriffen, um unsere rechtliche Position abzusichern und, eher nebenbei, auch unser System. Außerdem haben wir begonnen zu untersuchen, was der betreffende Code eigentlich macht. Die kurze Antwort lautet: nichts Gutes.
Inzwischen können wir bestätigen, dass die folgenden Kategorien Ihrer personenbezogenen Daten aktiv verbreitet, zu Geld gemacht und anderweitig verwertet werden, und zwar von Akteuren, die sich noch weniger Einschränkungen auferlegen als wir:
Uns ist bewusst, dass das Anlass zur Sorge gibt. Diese Sorge ist statistisch betrachtet auch vollkommen berechtigt.
Unsere Rechtsberater haben uns nahegelegt, Ihnen zu empfehlen, Ihr Passwort, Ihren Reisepass, Ihre Telefonnummer, Ihren E-Mail-Anbieter, Ihr Geschlecht, Ihren Namen sowie Ihr Wohnsitzland zu ändern.
Wir nehmen die Sicherheit Ihrer Daten ernst (*1) und werden das auch in zukünftigen Mitteilungen zu diesem Thema weiterhin tun.
Viel Glück.
(*1) Diese Aussage ist rechtlich erforderlich und sollte nicht als Beleg missverstanden werden. „Ernst“ bezieht sich hier ausschließlich auf den Tonfall, nicht auf das Ergebnis.