In a new blog post published by one of KDE’s lead developers, Martin Gräßlin – responsible for maintaining KWin window manager among other things, the author explains the rationale behind recently pushing a new feature to mainstream KDE that removes the ability of users to run Kwrite or Kate text editors as root.
His base argument is that it’s not secure since malicious code (in another program for instance) may take advantage of an app opened as root and utilize it for executing a malicious operation.
“The problem with starting GUI applications as root is that X11 is extremely insecure and it’s considerable easy for another application to attack this.”
Says Martin.
As the majority of experienced Linux users may attest, using text editors in privileged mode (aka root) is an integral part of many Linux users on a regular basis, assisting them in achieving different mundane goals.
It’s important to mention that Martin’s newly added code will not leave users empty-handed nonetheless, instead it will direct users (some say educate) to use another tool called sudoedit instead which allows users to only edit certain files or use certain commands.
Needles to say sudoedit may form yet another layer in an already full of layers learning curve ahead of the assiduous Linux user.
Although Martin stresses the importance of such feature (or should I call it the removal of one) from a security point of a view (and rightfully so may I add), the majority of the community seem to have a complete opposite view about it.
For example, the following comment posted on Martin’s blog reflects a substantial part of the community’s feelings and thoughts, expressed in other comments as well:
“I find this absolutely unacceptable, and hope distributions will patch this nonsense out. kdesu kwrite is a very common operation (I do it regularly), and blindly refusing to run as root also breaks running the application in root sessions. And people will just use something else, just as Krusader’s easily accessible root mode, or a non-KDE editor.”
Excluding the wish that distributions will ‘patch this nonsense out’ (since it’s highly unlikely), the comment does raise a valid point – preventing users from opening KDE’s text editors as root might burden users so much so to drive them away to use a non KDE editor.
Another comment also expresses the annoyance users experience due to the current situation further arguing that the offered solution will only amplify that feeling of nuisance:
“… when you edit file to [which] you don’t have permissions (not necessary system files) and when you finish, and you try to save it you are getting message that you cannot do that and have to redo everything again.”
From both comments above, it’s quite clear that neither the current nor the offered solution are optimal from a user perspective.
From a developer’s point of view, looking at it from a security stand point, the current solution clearly isn’t a winner and the proposed solution is not bulletproof either.
So what can and should be done instead then? Well there is a proposal which also arises more than once through users’ comments and appears to be aligned with Martin’s view as well.
The proposal suggests to employ an already existing Linux mechanism, namely Polkit (PolicyKit, a component for controlling system-wide user privileges) by integrating it into KDE’s framework, thus whenever the user is doing a task which requires elevated privileges (root) the Polkit mechanism would get into action and will prompt for password in order to continue.
To that Martin answers: “One step at a time.”
