https://bugs.kde.org/show_bug.cgi?id=497273
--- Comment #3 from Marco Rebhan <m...@dblsaiko.net> --- (In reply to Noah Davis from comment #1) > (In reply to Nate Graham from comment #3) > > Now, I would like it to eventually be ported back to use the portalized > > screenshot system, but only once we can ensure an adequate UX that doesn't > > prompt the user to confirm doing what they just explicitly said they want to > > do. As a result no actual security wold be gained by this as Spectacle would > > either be whitelisted by the system, or allowed once by the user with that > > permission being remembered over time. I agree, when taking a screenshot through Spectacle it should not ask for permission (or at least, at most once). Anything else would be annoying. > > However the interface is also useful for users automating their own > > workflows. We can't prevent the users from doing something useful simply > > because it *could* be abused. This would be like nailing someone's windows > > shut to protect against the threat of someone nefarious climing into an open > > window. That's not real security. Yeah, I would also not want the option to be removed from the Spectacle CLI for that reason. It's good to be able to automate this. > > As such I'm quite dubious about this suggestion. If your threat model > > involves untrustworthy local software having shell access, you have already > > lost the battle. *Any* software you run including untrusted programs can do this since everything has access to exec/posix_spawn. Of course there is sandboxing tools to restrict this, but I feel like it's better to be secure by default rather than require explicit setup. > (In reply to Nate Graham from comment #7) > > I appreciate your understanding. > […] > > Personally I think what we should be striving for us to keep actively bad > > software out of our apps stores and software repos in the first place, and > > therefore off the devices of casual users who are least able to manage the > > risks of malicious apps. > > > > But this is a much larger topic. :) I actually do agree with this whole part. However, there is a security system now whether we think it is a good idea or not, and it is also an unfortunate reality that untrusted programs do run on at least a huge part of people's computers (for example, proprietary games, even game mods, which can be malicious; see the recent malware shipped inside of a Cities Skylines 2 mod for example), so this is something that cannot be always 100% controlled. And I think that if implemented at all, security shouldn't be trivially bypassable like this. (In reply to Noah Davis from comment #2) > I don't think what you are asking for is possible. > Spectacle uses KWin's screenshot API for reasons mentioned in Nate's first > comment. > KWin's screenshot API doesn't have permissions, it just checks if the > requesting executable is in the same install prefix as KWin. > Spectacle can't know anything about apps that are trying to start a new > Spectacle process, so it cannot check their permissions. > I don't think Spectacle can choose which systemd scope it is used in. Ahh, I thought the X-KDE-DBUS-Restricted-Interfaces key in Spectacle's desktop file controlled this access. But no, what I'm thinking of is the following flow: 1. User starts application from the plasmashell launcher 2. plasmashell (or whatever) sets up new scope for this app, attaches information about the desktop file that launched it (something like this already happens, for example for System Monitor) 3. app ends up spawning a spectacle process or is spectacle itself, this spectacle process of course ends up in the same app's scope 4. spectacle tries to take a screenshot 5. (new!) kwin checks the process's scope instead of the process path and determines access based on that, shows confirm dialog if the user didn't confirm access to screenshots for this desktop file yet. the system can ship pre-existing rules to allow screenshots for spectacle when launched via its desktop file so it won't ask there This is roughly based on how it seems like macOS's permissions checks work. IMO this is something they got right. Implementing it like this is obviously something that would have to be done on Kwin's side, though. -- You are receiving this mail because: You are watching all bug changes.
