| Summary: | Improve dolphin behaviour in situations when user "doesn't have enough permission". | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | Diego <diego.ml> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | CC: | adrian, bcooksley, bluescreenavenger, bug, bugseforuns, cannewilson, drf, frank78ac, javier, kde, kdelibs-bugs, manu.dwarf, nalvarez, paulatkins673, richih-kde, ruurd, sendel2000, soccerjonp, tesfabpel, vdboor |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Diego
2009-01-01 16:25:07 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. 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. > 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.
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. 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 *** Bug 190348 has been marked as a duplicate of this bug. *** 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". Interisting news: GSoC authorization framework in good shape. http://www.gigabytes.it/2009/07/kde-authorization-library-first-step/ http://www.gigabytes.it/2009/07/kde-authorization-library-second-step/ http://www.gigabytes.it/2009/08/kde-authorization-library-final-step/ 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. 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. This will be addressed in KIO, I'm taking up this bug. See my last mail to kde-core-devel for more details To my comment #7: Why it can't give a shortcut to deactivate the setting of permissions like in mc? @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. 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. *** Bug 237281 has been marked as a duplicate of this bug. *** 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. 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. Any hope of seeing a similar mechanism implemented in KF5 version of KIO? @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. (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. *** Bug 243156 has been marked as a duplicate of this bug. *** Can this be moved to frameworks-kio, if this is still possible? How can this be moved to Frameworks-kio? this is filed under kio, which I think is now for KDE4? It seems there's substantial progress, thanks to a GSoC project! http://blog.chinmoyrp.com/gsoc/2017/05/05/kio-will-get-polkit-support-this-summer/ http://blog.chinmoyrp.com/gsoc%20kde/2017/06/18/new-upgrades-in-kio-file-ioslave/ *** This bug has been marked as a duplicate of bug 179678 *** |