Jan Schaumann

If you list AI as a "co-author" on a paper, I will stop reading. If you gave the AI a freaking name on top, I'll consider you lost. You'll have a long and difficult path ahead regaining any trust or respect.

Advanced Programming in the #UNIX Environment Week 4: time(3) is an illusion Having revisited the atime, mtime, and time in our last video segment, we now have to come to terms with time(3) itself. We'll discuss managing the data structures and handling arbitrary concepts such as leap seconds, timezones, and (ugh) Daylight Savings Time. It gets silly real quick. https://youtu.be/3N2aH1vUacQ For a lot more time based shenanigans, see also: https://www.netmeister.org/blog/epoch.html

Advanced Programming in the #UNIX Environment Week 4: atime, mtime, ctime In this video lecture, we start looking a little bit closer into what our systems think of "time", something that experts most accurately describe as a big ball of wibbly, wobbly, timey, wimey... stuff. In short, analyze how the atime, mtime, and ctimes of a file connect. https://youtu.be/ffYEEj5vnlw

Dear journalists: it's not "AI escaped", it's "AI companies failed to restrict the programs". Programs that did exactly what they were instructed to do. By those companies. Place the blame where it belongs.

Advanced Programming in the #UNIX Environment Week 4: /etc/passwd In this short video, we try to answer the awkward question "Mommy, where do UIDs come from?". We look at the /etc/passwd user database and identify the various fields before we look at how things can get weird. https://youtu.be/fv16TWDnLYM

"Winning AI" -- people keep using those words. I don't think they mean what they think they mean. https://www.netmeister.org/blog/winning-ai.html

Advanced Programming in the #UNIX Environment Week 4: Directory Size Let's dive deep into the structure of the directory on a traditional Unix File System and see how its size is independent of the file sizes of its entries, but dependent on the filename lengths. We'll also use hexdump(1) to cheat a bit and look at the actual directory structure on disk. https://youtu.be/gY0SE-71LZA

Advanced Programming in the #UNIX Environment The objective of this class is to learn and understand the interfaces, libraries and concepts we cover as well as to actually write code. This requires struggling with code, to work your way through your problems rather than copy together AI generated snippets and pasting errors into a prompt. Below are my updated slides on the use of AI in this class, and this is our policy: https://stevens.netmeister.org/631/use-of-ai.html

If you create a symlink to a symlink to a symlink ... at some point your system will return ELOOP. A reasonable system has that value defined in sys/param.h as MAXSYMLINKS or as sysconf(_SC_SYMLOOP_MAX). On Linux, the value of MAXSYMLINKS in sys/param.h is 20, but the kernel actually uses 40: https://elixir.bootlin.com/linux/v7.2.8/source/include/linux/namei.h#L14 The sysconf(3) man page on Linux documents _SC_SYMLOOP_MAX, but then fails to actually retrieve that value. Good job, Linux. You illustrate why I use #NetBSD to teach this class.

Advanced Programming in the #UNIX Environment Week 4: getpwuid(2) and /etc/groups After having discussed all the account fields in /etc/passwd, we now look at the library functions used to look up that information. We learn about how primary and supplementary groups are handled as well as how the hashed passwords are stored outside of the world readable /etc/passwd file. https://youtu.be/aomkx6_aWpc

You're right - AI _is_ useful. Your use of it provides an important signal to me: 1) For writing: "I didn't care to put the effort in to write this myself." 2) For coding: "I don't care if I understand the solution." 3) For vuln impact analysis: "I don't understand the code base nor the attack vector." Or shorter: "I do not care about the details." This, of course, on top of the other ethical problems with AI. It's a strong signal, and I see it everywhere.

Advanced Programming in the #UNIX Environment Week 4: The Unix Filesystem This week, we'll take a closer look at the Unix Filesystem (UFS). In our first video segment, we visualize how the filesystem structures the disk and organizes files and directories. We illustrate how directory entries are created and moved around. https://youtu.be/kY4JAXYyByQ

Advanced Programming in the #UNIX Environment Week 4: Directories In this video, we take a look at how directories are created and removed, as well as how to move around the filesystem hierarchy. We also learn how directory permissions are applied, why the 'cd' command must be a shell builtin in order to work, what happens when you remove a directory you're currently in, and we revisit our simple ls(1) clone from week 1, using opendir(2) and readdir(2) to list files. https://youtu.be/xZ7dNXZ58G8

Advanced Programming in the #UNIX Environment Week 3: recap Slides from tonight's class, summarizing the last few videos and adding a few more bits (haha, get it?) about how the umask works. https://stevens.netmeister.org/631/03-f26.pdf

There isn’t a 10% chance that AI will kill all humans in the future via Skynet or the Paperclip Maximizer. But there’s a 100% chance it’s already doing so: mandating water wasting, air polluting, fossil fuel powered data centers, environmental regulations are lifted for these companies and even their feeblest greenwashing commitments to carbon neutrality or renewable energy sources are pulled while record heat and wildfires kill more and more people to teach AI how to spell “strawberry”.

Advanced Programming in the #UNIX Environment Week 3 (and 4, kind of): Union Mounts and Whiteout Files One of the file types we've encountered are those of type S_IFWHT, so called "whiteout" files. But what the hell is that?? Let's illustrate! We describe the concept of union mounts and see what happens when a file in the upper layer is removed while the same file still exists in the lower layer: a whiteout file is created to cover up the lower file. https://youtu.be/MkFExG9jhEE

Advanced Programming in the #UNIX Environment Week 4: Links In this video lecture, we'll take a look at the system calls used to create, remove, and rename both hard- and symbolic links. We'll compare expected output against trivial implementations of the ln(1) and mv(1) commands. https://youtu.be/0l8o2goJ1kc

Kinda feel that unless this is a Vercel-only thing, dropping this note seems irresponsible to me: If it affects Firecracker, you need to coordinate with AWS. Amazon should not appreciate prior disclosure. If it's generic, you absolutely need to coordinate with Everybody(tm). That could take weeks. (And $50K seems reasonable for a Vercel-only thing, but a generic KVM escape ought to be worth a lot more.)

This has absolutely entered my vocabulary. On the off-chance that you haven't seen this definition yet:

Meat proxy

1. A person who forwards AI-generated text, code, or other output without reading, understanding, or validating it. The person acts only as a relay between the AI system and the intended recipient.

https://sfisms.org/meat-proxy

(Also: sf-isms.)

Tee hee, HN stumbled upon my AI rant blog post and boy is that a different discussion from Lobsters. ✌️

Advanced Programming in the #UNIX Environment Week 3: umask(2) In this video lecture, we'll take a look at what file ownership and permissions are applied when we create a new file. In the process, we'll learn about the concept of a process's "umask", and look at how the 'umask' shell built-in is implemented. https://youtu.be/bRAR2bv2HSM

Really looking forward to the first large-scale OpenAI / Anthropic API outage, where 85% of the industry will be flopping around trying to remember how to hello-world on their own while execs google "how to write an email".

Advanced Programming in the #UNIX Environment Week 2: File Sharing In this final video lecture segment for our week 2 materials, we take a look at what it means when multiple processes access the same files and what the implications of that are on the syscalls we know. We conclude with a look at /dev/fd on different operating systems, including #NetBSD, #macOS, and #Linux. https://youtu.be/CAbUtc86ULw

Advanced Programming in the #UNIX Environment Week 3: stat(2) intro In this video lecture, we meet our new best friend, the 'struct stat'. We'll cover the stat(2) system calls and begin discussing each of the fields in the struct, often by example of the ls(1) and stat(1) commands. In this way, we begin learning more about how the Unix File System is implemented. (Note that the output of stat(1) on #NetBSD is different from that on #Linux.) https://youtu.be/veFwXrEHPsk

Advanced Programming in the #UNIX Environment Week 3: UIDs and GIDs In this video lecture, we'll learn a little bit more about file ownership and the user IDs of a process (real, effective, saved) by looking at the seteuid(2) and setuid(2) system calls and experimenting with setting the setuid bits and observe the file access we gain. https://youtu.be/YlcF3ncTQpo

Advanced Programming in the #UNIX Environment Week 01, Segment 01: Introduction In this video lecture, we provide an introduction, discuss the purpose of the class, the syllabus, student expectations, as well as available resources. Note: The videos in this series were mostly created in 2020. A few things have changed since then. Specifically, consult the course website for updates regarding the assignments. https://youtu.be/BsB9Cg6yJc4

Advanced Programming the #UNIX Environment Week 1: UNIX History We cover the early days at Bell Labs, USL vs BSDi, the birth of the BSDs and #Linux, and how we got from Ken Thompson playing "Space Travel" on a PDP-7 to Unix running on your phone, fridge, and TV. https://youtu.be/3H7SQWTR6Dw Scroll along through it all here: https://levenez.com/unix/unix.pdf

Advanced Programming in the #UNIX Environment Week 3: chmod(2) and chown(2) Having seen a lot of examples in our previous videos of creating files, changing their ownership, changing their permissions, we now focus on the system calls that are used to implement the chmod(1) and chown(8) commands. https://youtu.be/5MJmCanZDyk

Advanced Programming in the #UNIX Environment Week 2: File Descriptors To introduce the concept of file descriptors, let's start with a simple question: how many file descriptors can a unix process open? Finding the answer helps us introduce a few different limits that may apply across the system, for a given user, or just a process. As a fun exercise, try setting "ulimit -n 0" in your shell and see what happens. Can you explain why? https://youtu.be/h5A1OQjuCqk

Advanced Programming in the #UNIX Environment Week 2: open(2) and close(2) Having introduced the concept of file descriptors, let's look at what happens when we try to create a file, "create" an existing file, open an existing file, truncate a file, and look at the various other flags we can pass to open(2). We also note the perhaps surprising number of ways in which open(2) can fail and take a look at openat(2) and TOCTOU defenses. https://youtu.be/QnL4eYpb5Iw

Advanced Programming in the #UNIX Environment

Week 3: struct stat st_mode

In this video segment, we're looking at how the traditional permissions defined in the struct stat st_mode are applied. You want to pay particular attention to the permissions on directories and the order in which they are checked. One thing that often surprises newcomers is that to delete a file, Unix does not care about the permissions on the file, only on the directory it's in.

https://youtu.be/vS6abFjN3ZY

Advanced Programming in the #UNIX Environment Week 1, Unix Basics We write our first trivial program, which promptly segfaults and gives us a chance to explain function forward declarations and maneuvering man pages and set our default compiler flags ("-Wall -Werror -Wextra"), then proceed to write the most trivial versions of cat(1), ls(1), and even a rudimentary shell including a signal handler. https://youtu.be/w3spRzZ8bSA Slides: https://stevens.netmeister.org/631/01-basics.pdf

Advanced Programming in the #UNIX Environment

In this class, we use #NetBSD as our reference platform. In addition to our shared shell server, here are some ways you can install NetBSD:

• put it on e.g., your laptop: https://netbsd.org/docs/guide/en/chap-exinst.html

• use VirtualBox: https://stevens.netmeister.org/631/virtualbox/

• use UTM: https://stevens.netmeister.org/631/utm/ (Video instructions: https://youtu.be/hCqfmuG5Acc )

• use or create an AWS image: https://stevens.netmeister.org/615/netbsd-amis.html

• create your own NetBSD #Linode: https://www.netmeister.org/blog/netbsd-on-linode.html

Advanced Programming in the #UNIX Environment Week 2: read(2)/write(2)/lseek(2) In this video lecture, we will go into the details of the read(2), write(2), and lseek(2). We'll also do a few weird things with file descriptors, and take a look at how we can ensure I/O efficiency when making these system calls. https://youtu.be/EUUPw8MOV_A

Quick reminder: Models Don't Go Rogue https://mail.cyberneticforests.com/models-dont-go-rogue/ (Now AI companies and their cultists on the other hand...)

The real joke is of course that he probably first wanted to rename it to "American Intelligence", but then he wouldn't be able to tell who's bootlicking or not when saying "AI". As always, it's a loyalty test and fealty signal.

OpenAI now announces that its latest model is _so_ advanced that it considers itself too dangerous to be used by anybody and consequently has deleted itself. The crowd goes wild at the prospect of buying stock in a company that now focuses 100% of its tremendous efforts and compute power on _not_ building AI. It's difficult work, but for the sake of mankind, no sacrifice is too stupid.

@lcamtuf@infosec.exchange Oh, and two random corrections: " it’s not trivial tell" -> "it's not trivial _to_ tell" "it’d hard for" -> "it'd _be_ hard for" :- )

New plonk just dropped.

Heh, the Register picked this up, so if you want to 🍿, there's a bunch of comments there, too: https://www.theregister.com/security/2026/07/22/linux-kernel-team-publishes-432-cves-in-two-days/5276497

So, uhm, at this point, seems like local privilege escalation vulnerabilities are numerous enough that you can pretty much assume that any local user can become root and escape most containers, yes? "FragGap" LPE via IPv4/IPv6 UDP corking path https://blog.qwerty.or.kr/en/posts/cdf3008a-c1a4-4eca-a373-aa3a2bcf1489/ https://github.com/qwerty-po/security-research/tree/cve-2026-53362 https://github.com/sgkdev/ipv6_frag_escape

One side-effect of this language choice is self-deception on Anthropic's (or any / all AI developers') part. If you use language of agency, you assign yourself the role of observer, not that of the developer who controls the system. As a result, we get a lot of "we're trying to figure out how this mystical Claude thing we stumbled upon works" -- ttreating a computer program almost as an evolved entity -- which I find just flat out irresponsible.

I've used the same metaphor ("using AI for assignments is like paying somebody to go to the gym for you") for my students for a long time now. https://www.schneier.com/blog/archives/2026/07/should-you-use-ai-for-a-task-heres-a-simple-way-to-decide.html (Going forward, I may also have to play "Hacks" Season 5 Episode 6 for my students on the first day of the semester.)

@SteveBellovin@infosec.exchange This was posted to the pqc-forum NIST list: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/2r2u6SbHun4 https://www-cdn.anthropic.com/e8d50c167ad47beeb03d6109a4a484be95cb38ea/hawk_key_recovery.pdf

Anthropic is also intentionally presenting Global Workspace Theory almost as a fact, saying (in effect) "this is how it works in humans", which I think is also misleading. We don't know that this is how consciousness works. (And if GWT does play a role, it may not even solve the hard problem.) Calling information a model uses "access conscious" because it can be "verbalized" (i.e., produced in words) is tautological in a model that exists solely as a word processor and generator.

AI is notoriously verbose, often producing pages and pages of output that then, inevitably, the recipient feeds back into _their_ AI to summarize. AI companies are charging customers by the token, both input and output. It's almost as if there was some sort of connection there.

Anyway, here's the post by Anthropic (which still is _interesting_ of course): https://www.anthropic.com/research/global-workspace I haven't yet read the entire paper, nor the external commentary (which I appreciate being requested): https://transformer-circuits.pub/2026/workspace/index.html https://www-cdn.anthropic.com/files/4zrzovbb/website/cc4be2488d65e54a6ed06492f8968398ddc18ebe.pdf