Bug 179289 - Improve dolphin behaviour in situations when user "doesn't have enough permission".
Summary: Improve dolphin behaviour in situations when user "doesn't have enough permis...
Status: RESOLVED DUPLICATE of bug 179678
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
: 190348 237281 243156 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-01 16:25 UTC by Diego
Modified: 2017-10-11 11:34 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Diego 2009-01-01 16:25:07 UTC
Version:           1.1.80 (using 4.1.85 (KDE 4.1.85 (KDE 4.2 Beta2)), 4.1.85-6.fc10 Fedora)
Compiler:          gcc
OS:                Linux (i686) release 2.6.27.9-163.fc10.i686

The basic idea is the same of this bug:
https://bugs.kde.org/show_bug.cgi?id=141604
but with some updates (e.g. use PolicyKit instead of sudo).

A similar idea (analogous considerations) for the save dialog is described here:
https://bugs.kde.org/show_bug.cgi?id=178590
Maybe it is possible to (eventually) share some code...

The problem:
"You don't have enough permission" confuses a lot non technical users.

Example:
Suppose your new foo device requires x.y version of the bar firmware. You found in the internet or somewhere else that you have to download the firmware file and you have to copy it to /lib/firmware. So you:
- download the firmware;
- open Dolphin;
- split view in two;
- open in the left side the directory where you downloaded the firmware and in the right side /lib/firmware;
- drag and drop the firmware to the desired directory;
- get a laconinc windows telling "Permission denied. You cannot write to /lib/firmware".

Currently the only solution is running Dolphin as root (it is bad to run a whole application as root only to perform a single specific action) or to copy the file from the command line using su or sudo.


Proposal:
A possible intutive solution could be:
- check if the user running the GUI can perform the desired action;
- if he can then perform it;
- if he can't then open another dialog asking if he wants to abort the action or he wants to be asked for password to perform the action as privileged user;
- if the user chooses to be asked for password then do the things needed to actually perform the action (PolicyKit-KDE?).
Comment 1 Diego 2009-01-07 18:56:54 UTC
A brief and useful explanation of how PolicyKit works is available on issue 144 of the commit-digest:
http://commit-digest.org/issues/2009-01-04/

It describes some aspects of the proposal I made from a more developer oriented POV.
Comment 2 R.F. Pels 2009-02-27 22:16:44 UTC
I think this is a bad idea because it opens the user to social engineering attacks. We really do not want to be too user friendly in this area. Being difficult here is an asset, not a liability.
Comment 3 Diego 2009-02-28 12:02:27 UTC
> I think this is a bad idea because it opens the user to social engineering
> attacks. We really do not want to be too user friendly in this area. Being
> difficult here is an asset, not a liability.

Of course security is one of the most important things to keep in mind but I think a compromise is feasible. Isn't security itself considered a sort of art of compromise?
For sure OpenBSD is more secure than Ubuntu, but do the "average user" like more to work with Ubuntu or OpenBSD? Is Ubuntu an "unsecure" distribution or is it just a good trade-off for the day to day and office usages?

What should be investigated here is the best point of trade-off between security and user-friendliness.

Forcing the user to use the command line could be considered somewhat more "secure" if the user itself is knowing what he's doing. On the contrary most of the users are forced to copy-and-paste weird bash combos to make their hardware to actually work or to configure a specific service.

If you ask a user to issue this command:

sudo cp my-wireless-card-firmware /lib/firmware

the user will ask itself: what's "sudo"? what's "cp"? For the sake of making his hardware to work as early as possible he will issue the command without even asking what he's doing. Isn't this the weak point where social engineering attacks?

On the contrary if you ask him to "Open the FILE MANAGER Dolphin", then click on the "Split View", on one side go to the directory where the firmware has been downloaded, and on the other side to go to the /lib/firmware directory, and then to drag and drop the firmware file from one side to the other he will be more aware of what he's doing, lowering the possibility of a social engineering attack. Moreover in the window where you'll ask him the appropriate password you'll be able to warn him in a graphical way about possible risks of performing the action.
So the user will more likely face that he's:
- doing a file management action;
- copying a file from a directory to another directory;
- being asked privileged user permissions through a graphical window asking him xyz user's password and warning him about possible risks (and the warning is difficult to be hijacked because it's implemented in the system itself, while no warning is issued when you "sudo cp").


Moreover many wiki guides suggest the "average users" to run file managers / text editor as root which is quite weird because the application itself can have  security flaws, so you're giving away root level privileges to eventual attackers.
With the solution suggested you're performing only the required action as privileged user, minimizing the "weak points".


So further discussions on security are mandatory, but not implementing this feature because "user friendly" means "unsecure" is a bit non-sense. I'm sure a good and reasonable trade-off can be achieved. And good trade-offs is what security is all about.
Comment 4 Anne Wilson 2009-03-02 18:21:33 UTC
I'm not qualified to comment on practical aspects, but for me, minimising the activity as root is a definite benefit.  I've always considered it an annoyance that I can't do this, but I do think that it actually would be more secure than the current method.
Comment 5 Diego 2009-03-23 11:52:02 UTC
For the record here there's some discussion about this bug:
http://lists.kde.org/?l=kde-devel&m=123575179410402&w=2
And (much more important) here there's a proposal / draft about "an API to let KDE applications acquire high level privileges in a secure and multiplatform way":
http://mail.kde.org/pipermail/kde-windows/2009-March/003618.html
Comment 6 Frank Reininghaus 2009-04-22 20:55:48 UTC
*** Bug 190348 has been marked as a duplicate of this bug. ***
Comment 7 Victor-Philipp Busch 2009-05-27 15:00:45 UTC
Hello,

everyday I see a problem with our users:

If they copy a file over another file and they are not the owner and the rights are a little bit different, they see an error message.

If they copy a lot of file at once, there are lot of error messages and the users are very angry about dolphin and KDE.

Can there be a option to deactivate setting of rights? For example, you can you can deactivate it in "Midnight Commander".
Comment 9 Richard Hartmann 2009-08-16 12:43:06 UTC
To further elaborate on #8: If this functionality is taken down to KIO level, dolphin and every other application gets this functionality for free so it makes sense to not fix this in Dolphin explicitly.

The GSoC student is planning on doing that as you can see in the comments of the third link. No way to deep-link to it, sorry.
Comment 10 Diego 2009-08-16 14:03:48 UTC
Here's the link:
http://www.gigabytes.it/2009/08/kde-authorization-library-final-step/comment-page-1/#comment-105
So I think it would be fine to mark bug #178590 as duplicate of this (there's more information in here), and to reassign this to KIO.
Comment 11 Dario Freddi 2009-08-21 21:01:26 UTC
This will be addressed in KIO, I'm taking up this bug. See my last mail to kde-core-devel for more details
Comment 12 Victor-Philipp Busch 2009-09-16 13:19:19 UTC
To my comment #7: Why it can't give a shortcut to deactivate the setting of permissions like in mc?
Comment 13 Diego 2009-09-16 14:57:05 UTC
@comment #12:
It would be an unoptimal solution as, for example, it will not work on Windows.
By the way if in MC you can deactivate permission without being asked for root password: well, that's pretty unsecure. If not, well, that's not too different from what it's going to be implemented, except that the latter will be much less hackish.
Comment 14 Diederik van der Boor 2010-04-15 17:56:27 UTC
For all your information, this feature (getting admin permission to write a file) is implemented in Windows 7 and Windows Server 2008.

First time I noticed it, it looked so obviously smart to me, that I'd wish Dolphin to have this feature too. Seems like a nice case for KAuth.
Comment 15 Peter Penz 2010-10-11 16:46:08 UTC
*** Bug 237281 has been marked as a duplicate of this bug. ***
Comment 16 Adrián Chaves (Gallaecio) 2012-08-31 21:48:54 UTC
It’s been more than a year since this task was updated the last time. Is there any ongoing work on this? I see it is assigned to Dario, but I think he is bussy with other stuff already (http://drfav.wordpress.com/), so maybe someone else wants to give it a try?

I got as far as “kdelibs/kioslave/file/”, which is where the actual operations to write to the filesystem happen and the “access” errors are “raised”, if you can call it that. But I don’t think I have the skills to perform the required changes to integrate KAuth into this code. I’m not even sure it is the right thing to do to integrate KAuth so deep.

I really hope someone else can and want to do it.
Comment 17 Janek Bevendorff 2012-09-07 14:49:48 UTC
Updating version since this report is set to status ASSIGNED.
Is anybody really working on this? If not please close this bug with a proper reason attached and/or split it up.

My 2 cents: Having some more root features wouldn't be a bad idea in general. Especially changing file permissions with kdesu as described in bug 161548 could be an improvement.
A general "Make me root" button, however, would be a pretty bad idea. Possible root actions should only be available where it's really of advantage for the user.
Comment 18 Diego 2013-12-11 13:20:41 UTC
Any hope of seeing a similar mechanism implemented in KF5 version of KIO?
Comment 19 Frank Reininghaus 2013-12-28 14:55:50 UTC
@Christoph: I see that you assigned this report to Dolphin. Could you elaborate on what kind of change we could make in Dolphin to implement the desired functionality? I had thought that KIO was the place where this should be implemented.
Comment 20 Diego 2013-12-30 07:50:13 UTC
(In reply to comment #19)
> @Christoph: I see that you assigned this report to Dolphin. Could you
> elaborate on what kind of change we could make in Dolphin to implement the
> desired functionality? I had thought that KIO was the place where this
> should be implemented.

For me too. I moved this bug to KIO.
Comment 21 Frank Reininghaus 2015-06-09 17:40:13 UTC
*** Bug 243156 has been marked as a duplicate of this bug. ***
Comment 22 bluescreenavenger 2016-05-22 03:46:34 UTC
Can this be moved to frameworks-kio, if this is still possible?
Comment 23 bluescreenavenger 2016-09-12 04:07:25 UTC
How can this be moved to Frameworks-kio? this is filed under kio, which I think is now for KDE4?
Comment 25 Christoph Feck 2017-10-11 11:34:55 UTC

*** This bug has been marked as a duplicate of bug 179678 ***