Debian's /tmpest in a teapot

Posted Jun 4, 2024 9:18 UTC (Tue) by smurf (subscriber, #17840)
In reply to: Debian's /tmpest in a teapot by epa
Parent article: Debian's /tmpest in a teapot

Of course there are uses for /tmp. Plenty of them. My email reader stores attachments there. Your compiler writes its transient files to /tmp. So does the initramfs builder. And so on.

The correct place for transient stuff that shouldn't be cleaned (and also doesn't need to survive a reboot), these days, is /run/user/‹uid›/.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 9:30 UTC (Tue) by bluca (subscriber, #118303) [Link] (28 responses)

Yes, it's a scratch area for private data (again: to be used with mktemp and friends) that is fine to lose at any time. It's not the right place where to _share_ data.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 11:36 UTC (Tue) by epa (subscriber, #39769) [Link] (27 responses)

But what data is “fine to lose at any time”, is my question. I am having a hard time thinking of examples. Most of the time software will break if the temporary file it was using gets deleted. There are a few applications which need a pure cache, entirely able to keep working if the cache files are deleted, but most current users of /tmp are not like that.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 11:41 UTC (Tue) by bluca (subscriber, #118303) [Link] (26 responses)

If any software actually exists that expects to drop critical files in /tmp, not touch them/access them for more than a week, and barfs when it goes back and doesn't find them, then that software is simply broken. It can be fixed in a number of ways as explained at https://systemd.io/TEMPORARY_DIRECTORIES/
I'm not sure it actually exists though, it really sounds like a strawman.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 12:24 UTC (Tue) by epa (subscriber, #39769) [Link] (3 responses)

I wouldn’t be so sure. Generally “anything that can go wrong, will go wrong” and a program that wasn’t envisaged to take a week could end up doing so — after all, it will not have an explicit check of time taken. It’s possible that an attacker could note the filename used, arrange to block the target process, and let its temp file get reaped. Then create a new one with the same name.

This is speculation, of course, but a generation ago the idea of deliberate hash collisions would have been seen as a straw man, or many similar “don’t do that” or “will never happen” scenarios.

Since the reaping period is defined to be at least 10 days (and not purely site-dependent) that takes away a lot of the worry in practice.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 14:34 UTC (Tue) by bluca (subscriber, #118303) [Link] (2 responses)

If "attacker takes over filename" is part of the threat model, _DO NOT USE /tmp_ for that data - no ifs, no buts, just don't.

All these tortured strawmen are exactly what I meant when I said "I am not really looking for philosophical discussions or lists of personal preferences or hypotheticals". If the new defaults do not work for you, just do the trivial one-line configuration change. Arguing about why your preferred configuration is the one true default and everything else is wrong is a waste of time and is not going to achieve anything at all.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 14:51 UTC (Tue) by epa (subscriber, #39769) [Link] (1 responses)

Thanks, sorry I didn't realize it was you. I didn't intend to waylay your work with hypotheticals -- it looks like a good improvement and certainly the status quo ante wasn't perfect either.

If "attacker takes over filename" is part of the threat model, _DO NOT USE /tmp_ for that data

Perhaps I am not understanding, but that seems to rule out /tmp for almost anything on a multiuser system. Many programs expect to create a file in /tmp and then reference it by name later. I know that the best way is to create the file in a single atomic action and get back the file *handle*, no longer caring about the name, but there are plenty of times when you want to run an external program and pass it the name of the temp file you created. For example running an external diff command to print the differences between two strings. I think that these cases outnumber those when you're content to use an anonymous file handle.

If you're saying that is never safe, not even when done with great care and exclusive mode opening and all the rest, then our positions are not so far apart. The safe uses of /tmp are a lot fewer than is common practice.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 14:58 UTC (Tue) by bluca (subscriber, #118303) [Link]

It really depends on the threat model and countermeasures and so on. Using an O_TMP in a mktemp subdir (with enough characters in the template) is most likely ok for things that need to be safe against pre-emptive hijacking and that are not high value - caches and whatnot. But if there's anything worth stealing - just don't use tmp, there are so many safer alternatives, and are not really new either - XDG_RUNTIME_DIR has been around for at least a decade, probably more.

For sockets - just don't. It is honestly baffling that there are still programs doing that, like tmux.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 15:51 UTC (Tue) by mb (subscriber, #50428) [Link] (21 responses)

> that software is simply broken

No, it's not broken. It worked just fine until you started deleting files.

> It can be fixed in a number of ways

Yeah. But you are breaking existing userspace here.
Is there a difference, if the kernel breaks userspace or if systemd breaks userspace?

I'm really annoyed by this.
Can you please give one valid reason, why you absolutely have to delete a couple of bytes from /tmp after it was sitting there without a problem for 10 days?

If we are talking about megabytes or gigabytes. Yeah. Fine. Establish a cleanup strategy, because it actually does help.
But deleting small files and sockets? Just don't. There is no way this is going to help anybody, but plenty of room for breakage.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 16:10 UTC (Tue) by bluca (subscriber, #118303) [Link] (20 responses)

> No, it's not broken. It worked just fine until you started deleting files.

Yes, it is, and no, it didn't, as the article says at the very top this has been the norm on other distros for a decade.

> But you are breaking existing userspace here.

Nothing is broken, this is made-up nonsense. Just stop wasting time and write the one line config file to customize your machine as you want it. Complaining is not going to change anything.

> But deleting small files and sockets? Just don't. There is no way this is going to help anybody, but plenty of room for breakage.

Size limit is not the only problem, especially on a tmpfs there is also an inode limit, and saturating a tmpfs with zero size files is very much possible and DOSes other uses of /tmp. So it's just as important to remove unused small files as it is large files to ensure the shared resource remains usable.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 16:31 UTC (Tue) by mb (subscriber, #50428) [Link] (19 responses)

>especially on a tmpfs there is also an inode limit, and saturating a tmpfs with zero size files is very much possible and DOSes other uses of /tmp.

Ok. Can you give us some numbers and show how that is not "made-up nonsense" (quoting yourself), please?

How many files must be created to exhaust the available space?
Which real world application is affected?
Traditional disk based /tmp surely has the same problem, right? So there has never been a version of Linux without this "problem". But there surely have been decades of Linux that don't delete files from /tmp at random times.

>write the one line config file to customize your machine as you want it

My machine _is_ configured the way I want and you are changing it. And I didn't read a plausible explanation for why this is needed, yet.

You are changing user interfaces. You are doing the very same thing that you constantly complain about.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 16:51 UTC (Tue) by bluca (subscriber, #118303) [Link] (18 responses)

> Ok. Can you give us some numbers and show how that is not "made-up nonsense" (quoting yourself), please?

Depends on the system, just check it out - df -hi /tmp

> But there surely have been decades of Linux that don't delete files from /tmp at random times.

Sure there have - tmpfiles.d has been deleting files in /tmp, in Debian too, for the past ~15 years, and before that there were things like tmpreaper. Other OSes like Solaris also delete stuff there by default. You are pretending this is some sort of new, last minute development - it isn't, it's ancient history.

> You are changing user interfaces. You are doing the very same thing that you constantly complain about.

Nonsense. Major version of distributions change things all the time, that's why we publish this thing called "release notes" where changes are noted. If you don't want changes, stay on the same stable LTS version forever. Distributions, including Debian, never, ever said "we won't break compatibility across major version upgrades", quite the opposite, every new release changes something - that's the entire point of doing a new Debian release. The parallel you are trying to draw makes no sense, as the kernel _does_ say " we do not break compatibility". That makes all the difference, and pretending it doesn't is just silly.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 17:28 UTC (Tue) by mb (subscriber, #50428) [Link] (17 responses)

>just check it out - df -hi /tmp

Ok.

>$ df -hi /tmp
>Filesystem Inodes IUsed IFree IUse% Mounted on
>tmpfs 4.4M 37 4.4M 1% /tmp

>$ for i in $(seq 0 100000); do touch /tmp/x/$i; done

>$ df -hi /tmp
>Filesystem Inodes IUsed IFree IUse% Mounted on
>tmpfs 4.4M 98K 4.3M 3% /tmp

So it takes ~4.5 million empty files to fill up the available inode space.

It doesn't convince me that this limit can be used to argue that possibly used files must be deleted after 10 days.

Is that limit hit more frequently than applications breaking due to deleted files?

Debian's /tmpest in a teapot

Posted Jun 4, 2024 17:38 UTC (Tue) by bluca (subscriber, #118303) [Link] (16 responses)

> It doesn't convince me that this limit can be used to argue that possibly used files must be deleted after 10 days.

There must be some misunderstanding here - I am not arguing for anything, not trying to convince you of anything. I'm simply explaining how things work and why. If you don't like how they work, that's too bad - feel free to configure your machine differently as already explained, you are free to configure your laptop or your desktop or your server as you see fit, it really doesn't make any difference to me, these settings are all configurable by design

Debian's /tmpest in a teapot

Posted Jun 4, 2024 18:37 UTC (Tue) by mb (subscriber, #50428) [Link] (15 responses)

>I am not arguing for anything

Well, but you should. You are changing the Debian world here.

>feel free to configure your machine differently

Keep in mind that you are changing my machine behavior here. You change how the Debian system works and I have to revert back to the old behavior.

It's the responsibility of you as a maintainer to have actual good reasons for a change. And you should be able to explain them. Yet, I did not see more than basically that you'd like it better if the files were deleted and "somebody else does it, too".

There is a huge responsibility with being a maintainer.
If you make a change that requires millions of people to change just one configuration line to get the old behavior back, you are wasting millions of hours of work time.
There should be a *good* reason for these changes.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 18:43 UTC (Tue) by pizza (subscriber, #46) [Link] (6 responses)

> Well, but you should. You are changing the Debian world here.

No, he (nor the other systemd developers) is doing nothing of the sort. *DEBIAN* is changing its own world.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 19:28 UTC (Tue) by mb (subscriber, #50428) [Link] (5 responses)

Please grep the Debian systemd package changelogs for "bluca".

Debian's /tmpest in a teapot

Posted Jun 4, 2024 20:46 UTC (Tue) by pizza (subscriber, #46) [Link] (4 responses)

> Please grep the Debian systemd package changelogs for "bluca".

Sounds like you need to file a release blocker bug with Debian, but since this is fundamentally about overruling a Debian packager's decision, you'll probably need to escalate this to the TC or to a full project-wide vote.

Either way, you'll need a better technical argument than "I don't like it and I can't be arsed to make a one-liner configuration change"

Debian's /tmpest in a teapot

Posted Jun 4, 2024 20:50 UTC (Tue) by bluca (subscriber, #118303) [Link]

It's even sillier than that, given it's only enabled for new installs, not on upgrades: "I don't like it and I can't be arsed to make a one-liner configuration change if I ever were to reinstall from scratch"

Debian's /tmpest in a teapot

Posted Jun 4, 2024 21:25 UTC (Tue) by mb (subscriber, #50428) [Link] (2 responses)

> Either way, you'll need a better technical argument

Yes. Changes don't require technical argument. "Only one reason is needed: I have decided as such." (bluca). And the users require technical argument against it. I got it and I will respect it.

I will certainly remember that rule.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 21:57 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> Changes don't require technical argument.

Except for the numerous times the technical merit of the "new" default has been explained, even in this thread. And then there's also the little detail where where the rest of the Linux world has been doing it this "new" way for about a decade. Those discussions (including technical arguments) are all part of their public record.

> "Only one reason is needed: I have decided as such."

Hate to break this to you, but the overwhelming majority of Debian packages also fall under this category - Both the packager and the upstream authors make countless such decisions every single day.

And again, if you (or whomever) doesn't like these decisions, feel free to invoke the Debian process for overruling a packager and/or upstream.

Second request

Posted Jun 4, 2024 21:59 UTC (Tue) by corbet (editor, #1) [Link]

I repeat: this has all been said, no more minds will be changed (if any ever were). I think we can stop this back-and-forth now.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 19:11 UTC (Tue) by bluca (subscriber, #118303) [Link] (7 responses)

> Keep in mind that you are changing my machine behavior here.

No. The next Debian release, due next year, will change your machine's behaviour in many ways, as it will be documented in the (lengthy) release notes. If you like it - good. If you don't - too bad, either reconfigure appropriately or stay on the current version until it goes EOL, and then start paying somebody to give you support beyond that.

> There should be a *good* reason for these changes.

Only one reason is needed: I have decided as such. Don't like it? Don't worry, you can have your money back, give me an address and I'll post you a cheque for £0.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 19:13 UTC (Tue) by bluca (subscriber, #118303) [Link]

(and to be really pedantic, as noted in the changelog, in fact the tmpfiles.d rules will not be applied to existing machines, but only to new installations)

Debian's /tmpest in a teapot

Posted Jun 4, 2024 19:26 UTC (Tue) by mb (subscriber, #50428) [Link] (1 responses)

>Only one reason is needed: I have decided as such.

Ok. That's the rule and I will also apply it to you.

A place to stop

Posted Jun 4, 2024 19:33 UTC (Tue) by corbet (editor, #1) [Link]

So ... once again we would appear to have reached a point where everybody has said their piece — several times — and any minds that might conceivably be changed will have been changed. This seems like a good place to stop this back-and-forth, please.

Debian's /tmpest in a teapot

Posted Jun 6, 2024 1:49 UTC (Thu) by jccleaver (guest, #127418) [Link] (3 responses)

>If you like it - good. If you don't - too bad,

Yep, that's bluca's and systemd's philosophy in a nutshell, right there.

Debian's /tmpest in a teapot

Posted Jun 6, 2024 9:13 UTC (Thu) by bluca (subscriber, #118303) [Link] (1 responses)

Correct - thanks for noticing! We pick sensible defaults that can be relied on, and empower you to customize them easily if and when needed.

Debian's /tmpest in a teapot

Posted Jun 6, 2024 12:16 UTC (Thu) by Wol (subscriber, #4433) [Link]

And was it *you* who decided Debian's policy to change Debian's defaults?

If it's just Debian deciding to adopt systemd's defaults, that's not down to systemd.

bluca can be a pain in the arse - can't we all - but unless he's responsible for Debian policy I fail to see how this has anything to do with him.

(Or is this the transition where now-stable is SysVInit, and next-stable is systemd, but even there I fail to see how this is down to systemd at all ...)

Cheers,
Wol

Debian's /tmpest in a teapot

Posted Jun 6, 2024 10:40 UTC (Thu) by smurf (subscriber, #17840) [Link]

@corbet asked us, multiple times, to stop the adversial and/or unproductive comments.

It's a freakin' default. You don't like it, change it. Other systems have been using the same default settings for literally decades.

If your argument boils down to "it's a change and I don't like it", well, open your window, there's way worse changes than putting /tmp into RAM looming on the horizon. Doing something about these would be a more productive use of everybody's time.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 11:34 UTC (Tue) by epa (subscriber, #39769) [Link] (2 responses)

But if the compiler writes its transient files to /tmp and they get deleted before the compiler has finished, it will break. Okay, the deletion time is typically much longer than a build runs for, but as far as I know this is not specified anywhere. Same for attachments — you could leave your desktop for a week’s holiday and expect it to be working on your return.

Debian's /tmpest in a teapot

Posted Jun 4, 2024 11:39 UTC (Tue) by bluca (subscriber, #118303) [Link] (1 responses)

It is specified - 10 days for /tmp and 30 for /var/tmp, and that includes mtime/atime/ctime. Have you _actually_ experienced that issue, or is it pure speculation based on cursory understanding of how this works?

Debian's /tmpest in a teapot

Posted Jun 4, 2024 12:02 UTC (Tue) by epa (subscriber, #39769) [Link]

That’s great. I had thought the reaping period was probably unspecified.

While in general I dislike timing-dependent effects, such as timeouts after inactivity on a socket connection, they are a fact of life.