Against /tmp

> The fix, way back when, should have been for login(8) to create a per-user temporary directory in a sensible place before it drops privilege, and set $TMPDIR so the user’s shell and child processes can find it.

Something like

    tmpdir := "/tmp/${USERNAME}"
    loop:
        rmdir(tmpdir, recurse=true)
        while not mkdir(tmpdir, 0o700, must-create=true)
    chown(tmpdir, user=$USERNAME, group=$USERGROUP)
    export("TMPDIR", tmpdir)

with /tmp having root:root owner with 0o775 permissions on it? Yeah, would've been nice.

Why not both, like Windows?

$HOME/.tmp for user operations and /tmp for system operations?

EDIT: I see from other posters it can be done. Why the heck isn't this the default?!

IMO even a home-level, per-user tmp directory isn't ideal (though it is better). In a single-user environment, where malware is the biggest concern in current times, what difference does it make if it's a process running under a different user or one that is running under your current user that is attacking you?

In other words, for many systems, a home-level temp directory is virtually the same as /tmp anyway since other than system daemons, all applications are being started as a single user anyway.

And that might be a security regression. For servers you're spinning up most services at bootup and those should either be running fully sandboxed from each other (containerization) or at least as separate system users.

But malware doesn't necessarily need root, or a daemon process user id to inflict harm if it's running as the human user's id and all temp files are in $HOME/.tmp.

What you really want is transient application-specific disk storage that is isolated to the running process and protected, so that any malware that tries to attack another running application's temp files can't since they don't have permission even when both processes are running under the same user id.

At that point malware requires privilege escalation to root first to be able to attack temp files. And again, if we're talking about a server, you're better off running your services in sandboxes when you can because then even root privilege escalation limits the blast radius.

> In a single-user environment, where malware is the biggest concern in current times, what difference does it make if it's a process running under a different user or one that is running under your current user that is attacking you?

Very true, and this is a real weakness of the UNIX (and Windows, even worse!) style security model in the modern environment. Android/iOS do a lot better.

> Android/iOS do a lot better.

They would if they were designed with the user's security in mind, instead of Google's/Apple's control.

But I disagree, they don't do better at all. Any software that wants to get access to everything just needs to insist.

Check pledge/unveil under OpenBSD. You get isolated software yet with freedoms.