Luigi Toscano wrote: > The user need to provide a password to access the privileged files, and > the only operation allowed will be the requested one against that file. > Running an entire application as root expose all the possible operations: > > https://blog.martin-graesslin.com/blog/2017/02/editing-files-as-root/ I understand the argument, I just don't agree that it makes sense. Upstream's point is that this opens up a privilege escalation possibility for malicious code running under your account. But let me point out that: 1. if you have malicious code running under your account to begin with, you have already lost. The malware can already read, encrypt and/or wipe all your personal data, which is the really important one (not the system files owned by root), it does not need ANY privilege escalation exploit for that. 2. if you are in a root session, the malicious code is already running as root and so there is no privilege escalation vulnerability at all. Yet, the check also prevents running the application in that context. 3. the privilege escalation is only possible if the user already voluntarily started the application as root and took the risk. The mere fact of allowing it is NOT a vulnerability. Therefore, consider the 2 cases: 3a) The user does not want or need to run the application as root. Then the change will not have ANY impact on the user. There is NO security issue either way. 3b) The user wants or needs to run the application as root. Then the change breaks the application for the user! 4. by refusing to run as root, you just make the user run another application without such a check instead, which has the exact same issue. Users will NOT use sudoedit or KAuth or whatever upstream wants to force them to use. So what security benefit does this change really bring? In the end, this only removes power from the user and brings no practical security benefit whatsoever. Free Software is not about having the computer dictate what the user can do! Kevin Kofler _______________________________________________ kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kde-leave@xxxxxxxxxxxxxxxxxxxxxxx