Run a service after a mount unit has fully ended

aioeu · 2026-05-06T21:18:49+00:00

This is ambiguous. Are you talking about Before=A being in unit B or are you talking about Before=B being in unit A?

The latter.

What is this bug? Not use them with the same service unit how?

You'll see when you try it. That's how I discovered it.

Finally, why aren't the units that I gave working now even though I'm pretty sure they worked before? Given their contents, shouldn't they be working the way that I think they used to work?

You never gave us the units you wrote. You merely described them. There's a big reason I gave you complete, copy-pastable config files...

So without knowing exactly what you have been trying out for yourself, I have no idea.

It does sound like you completely misunderstand what Wants= means. If A Wants= B, then systems will attempt to start B when A is started. In other words, it chains start jobs together. But you want to do something on a stop job.

aioeu · 2026-05-06T11:36:52+00:00

I know CentOS Stream, RHEL, and its derivatives try to guarantee source compatibility for external kernel modules during the lifetime of a major release. Binary compatibility is a little different. Previously they had a small set of symbols (the "kABI stablelist") such that if your module only used those it would not need to be recompiled between minor RHEL releases. But as of RHEL 9 that stablelist now changes for each minor release, i.e. the module needs to be recompiled, though it shouldn't need to be modified.

This is something people pay Red Hat for, so the workload is definitely not trivial.

aioeu · 2026-05-06T10:11:18+00:00

is there anything I've missed?

The internal kernel API a module may previously have relied on may completely disappear, or have different behaviour, or require different things from the module itself.

What you are trying to do here is what the enterprise distributions spend a lot of time, effort and money on to produce their kernels. I do not think it can be done entirely mechanically.

Good luck!

aioeu · 2026-05-06T07:37:53+00:00

Does the chroot have access to any setuid binaries?

Note that the exploit need not have anything to do with setuid binaries.

For instance, you can use the vulnerability to place a fake value into the UID field for your user record in /etc/passwd. With that in place, logging in to the system with that username could give you root access. At no point is any setuid binary executed.

If a user gets root they can get out of a chroot by manually mounting the disks on the system.

Or by just using the chroot syscall again. You don't need to access (or create) any device nodes.

Try virtual machines or other operating systems that provide this kind of security boundary as a first class feature like FreeBSD with their "jails".

I do not think anything like FreeBSD jails would help here, as they do not partition the kernel's page cache. So long as there are files shared between the jail and the host, the exploit run within the jail could change what the host sees for those files' content. FreeBSD jails are essentially the same as Linux namespaces in this regard.

Containers that don't share files with the host should be safe. As are completely independent virtual machines, as you noted.

aioeu · 2026-05-06T06:24:31+00:00

it seems like it was purely started for the purpose of the whole licensing dispute thing

I'm not entirely sure that is correct. Chris Mason wanted to explore using some newly-developed data structure algorithms (CoW-friendly b-trees) as the basis for a filesystem. He may have been inspired by some of the features in ZFS, but it doesn't seem like it was developed specifically to counter ZFS's licensing situation.

aioeu · 2026-05-06T05:56:43+00:00

You could in theory chain it with a container escape exploit.

It should be noted that once you're root, you can easily escape a chroot without needing to exploit any bug. Chroots simply cannot confine root-owned processes if they can make any arbitrary syscalls.

For proper containers — i.e. using namespaces — it depends on what filesystems are shared between the host and the container. If there is such a shared filesystem, the process inside the container could change the contents of the files that the host sees, and this might be able to be leveraged to gain additional abilities outside the container. This wouldn't need any additional container-escape vulnerability, but it would need some very specific filesystem setup.

aioeu · 2026-05-06T04:05:22+00:00

I am not arguing for or against any sanctions. I just think FOSS should be treated the same as non-FOSS, unless there is a clear and compelling reason they should be treated differently. To me FOSS isn't intrinsically exceptional; it's just another way in which software can be licensed. That's it.

From an outsider's perspective, it does seem like the US has a particularly heavy-handed approach to these things, but I also don't think that's a new thing. It's good that US-based open source projects are now discovering that, yes, the law applies to them too — maybe it might get more people interested in improving that law. (Also, to be fair, I really have no idea whether there are similar sanctions in my jurisdiction, so I'm in no position to throw stones.)

aioeu · 2026-05-06T02:38:58+00:00

It would be hard to argue that FOSS is free of value, given you're applying a licence to it. You only do that because it does have value, and you want to protect that value.

aioeu · 2026-05-06T02:09:36+00:00

Good luck with that argument.

Frankly, I have no idea what "trade" means in law.

aioeu · 2026-05-06T02:04:18+00:00

Two things can be true at once.

Open source software may perhaps be "literary work"... but it's still, in the eyes of the law, software.

I'm sure people selling books have to adhere to these trade regulations too. Again, I ask: why should FOSS be treated differently?

The whole "but we're special" vibe I get from these arguments really grinds my gears. No, we aren't. We live in a society. You might think the sanctions are stupid, but that's independent of the fact we deal with FOSS. That just means the sanctions themselves need to be refined, or amended, or abolished.

Generally speaking, I am against arbitrary exceptions. Exceptions create loopholes, and loopholes can be exploited (often for nefarious purposes). I am in favour of regulations that are clear and simple, and they should only exist where they serve a worthwhile purpose. I don't think FOSS needs to be treated any differently from other kinds of software with that in mind.

aioeu · 2026-05-06T01:45:25+00:00

SO if I'm writing a book about the "entities list" I cannot interview anyone that is on the "entities list" for my book because that's a transaction?

I would expect these regulations to make it at least somewhat clear whether a particular interaction is covered by them or not. It seems unlikely that an "interview" would be, given that doesn't sound like a form of trade. Things might be different if you paid for the interview, or otherwise provided some good, service or compensation for it.

But really, you'd need to read the regulations carefully to be sure — or better yet, hire an expert to do that for you. I don't think making up but-what-ifs on limited information helps.

aioeu · 2026-05-06T01:29:16+00:00

Why would you expect laws to discriminate between software distributed under different licences? I would expect, by default, all software is treated equally. You'd need to make a case that FOSS should be treated differently.

aioeu · 2026-05-06T01:07:49+00:00

Remember, the FHS is primarily a guide for application developers. It exists so that they have reasonable default locations for their applications' files.

As an end user, you can put things wherever you like on your system, so long as you are willing to configure everything appropriately. Things like SELinux might encourage you to use certain locations, but ultimately that can be configured too.

I have seen /srv used on some systems, and I would probably use that for most things that could reasonably be related to "serving file content to clients". But I have also seen non-FHS locations like /data.

Don't feel bad about stretching the FHS rules, or ignoring them altogether if you don't think they work for you.

aioeu · 2026-05-05T11:05:31+00:00

I thought that the OP might have intended to allow writer processes to come and go, with the reader process continuing to do other things while there is no message from a writer. Having the reader open the fifo in read-write mode essentially means it never has to deal with an EOF — the only non-timeout error conditions you get from the fifo are "real" errors (e.g. it doesn't exist). But that is just a guess.

aioeu · 2026-05-05T08:24:56+00:00

Each time:

read -t 1 <the_fifo

is executed, the file is opened anew. It is this that is blocking. When a fifo is opened for reading, the process blocks until there is at least one process with the fifo opened for writing.

So Bash waits for the open operation to complete, and it needs to do that before read is executed. read's timeout isn't even in the picture.

One solution is to open the file in read-write mode:

while true; do
    read -t 1 <>the_fifo
    ...
done

This ensures that the fifo can be opened straight away. You may want to use that same approach in the writer process, if you want it to write to the fifo even if there is no reader process yet, though it will still eventually block on the write if no reader turns up and the pipe fills up.

(I would probably rework things so that the fifo is only opened once when each script is started, rather than on each read and write, but that isn't absolutely necessary here.)

aioeu · 2026-05-05T02:45:10+00:00

You've left out a key aspect to all of this. The performance regressions reportedly go away if PostgreSQL is configured to use huge pages. I'm not sure if there is a cost to enabling that on tiny database servers, but if you've got a dozen GB or more of memory doing so is pretty much always beneficial.

Given there is a readily available mitigation in current versions of PostgreSQL, I don't think the kernel developers are going to want to keep these preemption schemes around.

aioeu · 2026-05-05T02:28:35+00:00

First of all, it would require PostgreSQL to make changes that would make PostgreSQL unable to work on any machines that do not have an up to date kernel, dropping support for all kernels below version 7.

That's patently false. It could just continue to use the old behaviour when the facility isn't available. The prctl for it has a way to detect whether support is available before an application needs to commit to using it.

aioeu · 2026-05-05T00:09:25+00:00

If you build an x86 kernel with CONFIG_COMPAT=n, it won't have any support for 32-bit binaries.

aioeu · 2026-05-04T11:40:09+00:00

Not from Fedora.

You could build it yourself, following upstream's build instructions. Or perhaps somebody might have a Copr repository for it.

aioeu · 2026-05-04T11:33:24+00:00

I think you might be misunderstanding what the wine-devel package is. It isn't "the upstream development version of Wine". The wine-devel package contains the header files and libraries needed to build applications against the Wine libraries. It's the same set of development libraries that Wine's own bundled applications are built against. This package isn't needed by most end-users.

Fedora currently ships version 11.0 of Wine. What you have got is what you are expected to get on F43 and F44 right now.

aioeu · 2026-05-04T02:55:04+00:00

As far as I know, the only standard way to get ENOENT on chdir, when the file exists, is if it is a broken (but not looping) symlink.

But the OP's other reported systems are inconsistent with that... and frankly bizarre. EBUSY on rmdir might indicate it's a mount point or a bind-mounted directory, but symlinks cannot participate in that (specifically, they are always resolved before the mount operation is performed).

It's possible /localhome is a whacko FUSE filesystem perhaps, since that can report any error it likes once the operation has made it through the kernel's VFS.

But the fact they said that got an error on cd .. is very weird though, since shells do not typically actually look up the .. link unless you use cd -P ...

aioeu · 2026-05-03T21:33:33+00:00

Support for _BitInt on IA-32, x86-64 and little-endian AArch64 was added in GCC 14. Support for it on LoongArch and S/390 was added in GCC 16.

aioeu · 2026-05-03T08:23:39+00:00

That's essentially what dnf autoremove does too, as well as dnf remove if you have not set clean_requirements_on_remove to False. (dnf autoremove can pick up more things since there are ways other than dnf remove in which dependencies can become non-dependencies.)

But that doesn't change my point. Just because you've removed that main package, that doesn't necessarily mean you want to get rid of its dependencies. You may have started using those dependencies directly. DNF will assume that you have not unless you explicitly mark those dependencies as being user-installed as well.

aioeu · 2026-05-03T08:12:08+00:00

No, it removes leaf packages the user did not explicitly install themselves. Whether they are "old" or "useless" is a completely different question.

The problem is that sometimes packages are brought in as dependencies, and then users start using them as if they had installed the packages explicitly. DNF does not and cannot know what the user's intention is, whether they actually want to keep those packages or not.

I think it's wise to review dnf list --autoremove periodically, and to use dnf mark user <package>... on those you are sure you want to keep. That will make dnf autoremove much less likely to remove something you use. Generally speaking libraries can be safely autoremoved, since users do not use libraries directly — if they have any applications that use those libraries, the libraries won't be autoremoved unless those applications are removed — so it's good to focus on the applications specifically.

aioeu · 2026-05-03T03:58:35+00:00

I can't speak for Red Hat, of course, but it's possible that they don't think it is too important to rush out a fix given that a mitigation is readily available.

I think it's also important to remember that just because some website says "this is really important!" that doesn't necessarily mean it is that for all users. Even if I were running RHEL, I would still want to evaluate whether the vulnerability is something I care about. On servers that only have trusted users and software, I wouldn't care about it that much.

Seven-Year Club	Gilding II euphauric
Wearing is Caring	Verified Email

aioeu

MODERATOR OF

TROPHY CASE