Does this also happen in Dolphin with Create New > File?

Yes.

Moving to KIO, then. What version of KIO or KDE frameworks do you have? I ask because this was supposed to have been fixed with Bug 404777 in Frameworks 5.87. So are you using 5.87 or 5.88, or an older version?

5.88

Looks like there's still a use case that needs to be fixed, then. Perhaps only copying got fixed, and file creation still suffers from the bug.

Maybe i am wrong, but when you copy a file you first create an empty one. Then you fill it in with the original content.

$ umask
0022
$ umask 0077
$ dolphin

then creating a new file with dolphin, checking the permissions I get `-rw-------`  which is correct.

Starting spectacle from the same terminal, I took a screenshot, clicked "Save", and the resulting .png file has the expected permissions.

So I think it's not an issue with KIO per se, rather the environment from where the screenshot app is launched doesn't have the correct umask? not sure.

I don't start apps from command line but rather from menu.
My bash has umask set to 0077.

To clarify, I meant that when you press e.g. the PrintScreen button, KGlobalAccel (?) starts Spectacle to take the screenshot, the way KGlobalAccel starts the app could be where the umask wasn't carried over.

I somehow would expect that stuff like umask is setup globally for any KDE/Plasma application.
If all of them use KIO to write files, then I would say KIO is the right place to fix it.
But I don't know enough about the overall architecture.

Confirmed under Fedora 35 with KDE Frameworks 5.89, though not sure KIO is the best place for this.
The issue is that KDE just doesn't seem to know about the user-defined umask at all. Not only KDE apps, any app launched through the Kickoff menu, like LibreOffice, will fail to honor the umask when creating a file. These same apps will behave as expected when launched from a shell, because the shell knows... The umask is usually set in the user profile or in the global profile. I hear that it should preferably be set in /etc/pam.d/login nowadays. I tried but it did not work any better.
We've been there before, long ago, and probably several times since then:
https://bugs.kde.org/show_bug.cgi?id=43172
An easy workaround then was to boot into non-graphical mode and type "startkde" by hand. Everything would work as expected, but if you went through the display manager, user-defined umask would be ignored.

Hmm, that might have to do with systemd, which Plasma has been using for a while, not sure though.

FWIW, I found:
https://github.com/systemd/systemd/issues/6077
https://github.com/systemd/systemd/pull/15318

so it "should" work, but I am not a systemd expert.

Thanks for the links. So for systemd the proper way to set umask would be inside /etc/login.defs (always globally)?
I edited this file, but it didn't solve the issue on my Fedora system.
Even if it did, doesn't KDE need to remain compatible with non-systemd systems? Maybe it shouldn't depend on systemd to be made aware of the umask? There are so many different ways to set it... I wonder if KDE shouldn't just query for it by attempting to issue a "umask" command as early as possible. Not sure how it would allow our Kickoff menu to have all apps (including non-KDE apps) inherit this umask at launch though... Or shouldn't the display manager provide it? (In my case, SDDM.) That'd be even earlier.
It'd be nice if someone with deeper technical knowledge than us users could step in.

If am reading this correctly, the issue is supposedly fixed by using pam_umask.so, which is probably what ArchLinux is already doing (but I don't know for sure).

(In reply to Ahmad Samir from comment #15)
> If am reading this correctly, the issue is supposedly fixed by using
> pam_umask.so, which is probably what ArchLinux is already doing (but I don't
> know for sure).

No, we're not. I will comment on the relevant downstream report.

OK, thanks. :)

This is now implemented downstream