*** Bug 22703 has been marked as a duplicate of this bug. ***

*** Bug 23010 has been marked as a duplicate of this bug. ***

*** Bug 28311 has been marked as a duplicate of this bug. ***

*** Bug 21434 has been marked as a duplicate of this bug. ***

*** Bug 60668 has been marked as a duplicate of this bug. ***

That would only work with local files. 

well, not if fish://root@server:/  is used for remote connections 

This has been on the wishlist for a long time and obviously other people have requested it as it has been dupped so often. Why haven't we got something like this yet?

I see 20 votes. That's nothing if you look at the "most wanted features" links on bugs.kde.org

*** Bug 81662 has been marked as a duplicate of this bug. ***

*** Bug 84165 has been marked as a duplicate of this bug. ***

*** Bug 83579 has been marked as a duplicate of this bug. ***

Hi,

here are some thoughts about this. 

- For file actions (move / rename / delete) this should be pretty straight forward: if current permissions are not enough and cannot be changed by the users (e.g. own write protection) then call something like "kdesu -c 'kfmclient [move|copy|..]' ...".

- For opening files with write access (e.g. in /etc): Context menu "Open as ..." (that perhaps only appears when user presses "Shift+RMB", like on Windows), then a list of users to choose from and/or a modified 'kdesu'.

- For executing binaries, I think there should be a "Run as .." option in the context menu (perhaps, like Windows does it, only when user presses Shift+RMB). Additionally (not related to this), IMHO there should be a warning for apps in /bin, /sbin etc. that they aren't graphical apps if the user clicks on them.
Most "root" apps aren't supposed to be called by a normal user from a GUI anyway, so we can probably even restrict this "Run as..." feature to apps in the KDE menu (and add the context menu there).
OTOH, if the user installs external programs from CD-ROM (or something) that don't come as a RPM, then he'd need this feature too.

- Other stuff, like getting access to hardware (eg. USB slots or whatever) that aren't accessible for normal users: IMHO that's a distribution specific problem, which shouldn't be handled by KDE. If the distro's default permissions are bad enough to not let users access their hardware, then KDE shouldn't try to work around this.

Any other cases?

Such a feature would really make file management a lot simpler.

Hope to see it in KDE4.

<quote>
A more user-friendly approach would be to bring
up a Super-User password box 
</quote>

This is exactly what Mac OS X do...

Wow, over 6 years!!  I remember wishing this when KDE 2.0 was about to come out....and then 3.0.  I guess I will now wish it for KDE 4.0.  I would pay a couple hundred $$ if it adds weight to my vote and helps gets this done--seriously.

For the time being, there's a service menu which can do something like that. It is limited, however (to actually opening the file using kfmclient, there isn't support for copy/move/delete in it).

The service menu is available here: http://www.kde-apps.org/content/show.php?content=36898

Would still be more than appropriate to see it built in in a more complete manner.

*** Bug 107691 has been marked as a duplicate of this bug. ***

7 years now!!!!! Outrageous - linux needs this. new users have not got the patience to go off and look for the way to do this is the shell - users want to move/edit/rename/delete files easily, that's what konqueror is all about!!

Its also easy to do in the shell - but for new users the shell is too much, and can cause confusion.

Vista does it - MAC OS does it apparently? - so why not linux?

looks as though linux is a sad 3rd in this race - so better get your skates on :-)

That feature request is certainly one of the best suggestions for Konqueror I've ever heard of. PLEASE implement it!

There are some important design issues to consider with this feature. It is very important that this doesn't turn into a Windows-Vista-like privilege escalation prompt where users become trained to regularly enter their password in order to get any work done. If users become accustomed to entering their password when prompted, they will give it to any app that asks for it. This is a serious security liability.

A proper design requires that privilege escalation must always be initiated by the user. ("sudo" and "kdesudo" have this property.) So here's a design-candidate for this feature that has this property:

1- Add a menu-option to Konqueror/Dolphin to escalate the privileges of the window. (This would be trivial to implement--it would simply launch another window via kdesudo to open at the same location.) This feature is never initiated automatically, but the users can do it when he/she want to do something that requires more privileges.
2- Update error messages to be more helpful. For example, a message that used to say "Insufficient permissions" would now say "The destination folder is owned by %s, but you are operating as %s. To open a window as %s, go to File->Change User".

Unfortunately, this design still isn't perfect. Another major advantage of "sudo" (or "kdesudo") is that escalated privileges are automatically reverted as soon as the operation has completed. My design-candidate would leave a privileged window open. A good design must have both:

1- user-initiated privilege escalation, and
2- automatic privilege reverting

Perhaps escalated windows would have a count-down timer that auto-closes after some period of time? Naw, that would be really annoying. Can someone please propose a better design idea that has both of these properties?

I agree 100% with everything Mike said. If it would simply ask for the password when deleting a protected file people would just enter it. Thus, my proposal is:

A menu entry: File->Impersonate... When you select it, a dialog opens and you can become root (or a different user, "root" is just already selected) and you always have to enter the password. After clicking on "OK" the same(!) window changes (I think it's quite confusing anyway if a different window opens all of a sudden) and becomes tinted in red with a nice balloon bubble in the lower-left of the window saying "Please be careful. You are working as root". Or tinted in orange if it's just a different user - but not root. Now, you get only one root command for free. No matter what. Either you right-click and select edit. Or you delete the selected files. Or you rename sth. Or you change file properties. Only one thing. After that, the window becomes normal again. The bubble disappears. But now there is a new menu entry below Impersonate... called "Impersonate again" and a simple(!) keyboard shortcut and toolbar button. A little bit like Find/Find again. If you want to become the same user again you can select this and don't have to go through the user/password dialog again. This works only as long as you keep the window open. Otherwise, you have to enter the password again of course. This forces the user to press i.e. F8 before doing a dangerous operation. I think that's not more annoying than having to enter sudo before each command in the terminal - less annoying rather because it's just one keystroke instead of five and it fulfills 1 and 2 of Mike's design requirements.

I don't think it is possible in general to know when a user has initiated a particular action. Some privilege escalations in Vista happen as a side effect of something benign, like browsing a website that requires a particular plugin. I don't see the point of having a menu uption that enables the possibility of privilege escalation. People would just turn it on by default to make their day easier, and if you made it so they couldn't do that, they would complain and somebody would fix it so they could. Remember password-less kwallet?

I support better error messages. Error messages should be verbose.

I always thought this bug is not about webbrowsing, plug-in-installation and stuff like that, but about the fact that Konqueror used to be the only application for file-management in pre-Dolphin days and you couldn't quickly edit a file like say /etc/fstab with it without starting a whole new Konqueror instance. Perhaps this bug should be moved over to dolphin? Or should I file a new one. Privilege escalation while browsing the web has lots more of security implications and I'm not in favor of implementing this at all.

This is similar to bug #16083

pritty old bug.Will someone look at it?

Still in Konqueror 4.3.0 (using Debian Unstable packages).

Various options are disabled in context menus and cartain keyboard shortcuts are ignored if I don't have permission. However, if I drag a file in a folder I don't own, I still get the Move/Copy context menu. Moving or copying files to a folder I don't control fails with an error message that I don't have permission. 

Dolphin has the same behavior (it should, since they use the same file browsing KPart).

When the Access Denied error pops us, I think there should be a prompt for privilege escalation if the owner of the location is root.

*** Bug 205267 has been marked as a duplicate of this bug. ***

*** Bug 16083 has been marked as a duplicate of this bug. ***

*** Bug 81209 has been marked as a duplicate of this bug. ***

*** Bug 265156 has been marked as a duplicate of this bug. ***

*** Bug 251817 has been marked as a duplicate of this bug. ***

@Peter: what do you think about this wish? Could it be implemented in Dolphin?

*** Bug 254238 has been marked as a duplicate of this bug. ***