445801 2021-11-20 11:50:44 +0000 Doesn't honor the system umask for newly-created files 2023-09-18 20:23:24 +0000 1 1 4 Plasma plasmashell general 5.23.4 Arch Linux Linux RESOLVED DOWNSTREAM https://bugs.kde.org/show_bug.cgi?id=404777 NOR normal 1.0 1 vincenzo.romano kde a.samirh78 arojas kde kde kdelibs-bugs-null nate plasma-bugs-null vincent.minder 0 oldest_to_newest 2079014 0 vincenzo.romano 2021-11-20 11:50:44 +0000 SUMMARY *** Screenshots are saved with 0644 permissions no matter what umask says*** STEPS TO REPRODUCE 1. Setup user-level umask to, say, 0077 (no permissions for G and O) 2. Take a screenshot and save it 3. Use konsole+cd+ls to check the screenshot file permissions. OBSERVED RESULT File has permissions 0644 EXPECTED RESULT File should obey umask (in the example should have permissions 0600) SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION 2080175 1 nate 2021-11-23 23:28:34 +0000 Does this also happen in Dolphin with Create New > File? 2080289 2 vincenzo.romano 2021-11-24 08:39:44 +0000 Yes. 2080493 3 nate 2021-11-24 20:20:30 +0000 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? 2080526 4 vincenzo.romano 2021-11-24 21:27:45 +0000 5.88 2080528 5 nate 2021-11-24 21:39:52 +0000 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. 2080533 6 vincenzo.romano 2021-11-24 22:10:56 +0000 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. 2081214 7 a.samirh78 2021-11-28 14:33:49 +0000 $ 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. 2081324 8 vincenzo.romano 2021-11-29 06:17:20 +0000 I don't start apps from command line but rather from menu. My bash has umask set to 0077. 2081335 9 a.samirh78 2021-11-29 08:15:22 +0000 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. 2081336 10 vincenzo.romano 2021-11-29 08:21:37 +0000 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. 2088018 11 vincent.minder 2021-12-24 21:46:56 +0000 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. 2088047 12 a.samirh78 2021-12-25 08:19:35 +0000 Hmm, that might have to do with systemd, which Plasma has been using for a while, not sure though. 2088048 13 a.samirh78 2021-12-25 08:40:27 +0000 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. 2088380 14 vincent.minder 2021-12-27 12:46:01 +0000 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. 2088570 15 a.samirh78 2021-12-28 11:21:29 +0000 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). 2088577 16 arojas 2021-12-28 11:46:15 +0000 (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. 2088579 17 a.samirh78 2021-12-28 11:52:40 +0000 OK, thanks. :) 2253826 18 arojas 2023-09-18 20:23:24 +0000 This is now implemented downstream