On Wed, Jun 24, 2026 at 11:41:07PM -0400, John Ericson wrote:

The current working directory, roughly, is *just* some global state
holding a directory file descriptor.

So's the descriptor table; what's the difference?

But I don't want that global state.

Don't use it, then... out of curiosity, does that extend to stdout et.al.?

If I am writing my userland program (that is not a shell), I would not
create the global variable. I do not appreciate the fact that the kernel
foists that state upon me whether I like it or not.

<wry> Kernel will have to live without your appreciation, I suppose. </wry>

Now obviously we cannot have a giant breaking change removing the notion
of a current working directory altogether. But we can allow individual
processes which don't want it to opt out, and that is what nulling out
these fields (and updating the path resolution code to cope with that)
allows.

There is no loss of expressive power doing this, because one can (and
should!) just use the `*at` and file descriptors. But there is, however,
the imposition of discipline.

So supply a library of your own and try to convince people to use it
instead of libc.  You'll have to anyway, seeing that a large and
hard-to-predict part of libc will be non-functional.  Which syscalls
are used by your library is entirely up to you.

Would that kind of thing added kernel-side assist the development of such
library?  Maybe, but I wouldn't bet too much on that - if you start from
scratch, you can trivially verify that you don't even attempt given
set of syscalls and if you use libc as a starting point, you get to
debug all the failure exits you've added...

The programmer (or coding agent) is
encouraged to do everything with file descriptors rather than path
concatenations etc., because they need to use `*at` anyways, and then
voilà, without browbeating anyone in security seminars or code review, a
bunch of TOCTOU issues disappear simply because doing the right thing is
now the path of least resistance.

I'm sorry, but the path of least resistance is picking a snippet from google
that will implement open(), etc., on top of your setup and using it.
_Especially_ if coding agents are going to be involved, precisely because
they'll do a convincing simulation of human duhveloper's behaviour, i.e.
"cut'n'paste it from the net".