File Browser Privilege Escalation Done Right

Even though there is a bug report on this for Nautilus, I didn’t include proper implementation of privilege escalation as one of The Top 5 Gnome/Ubuntu Usability Bugs I’d Love to See Fixed (well, it would then be six instead of five, anyway)—mainly because it’s not unique to Gnome.

I haven’t seen proper file browser privilege escalation implemented in Gnome, KDE, or Xfce. I haven’t seen it done well in Windows XP or Mac OS X, either.

Right now in Windows XP, if you’re not the administrator (and, for safety’s sake, you really shouldn’t be logged in as the administrator), there’s no easy way to temporarily become the administrator to edit a file or two. You can’t right-click the file and Open as… a different user. You can’t right-click Explorer and Run as… a different user. Basically, unless there’s something I don’t know about (Windows fans, please pipe up! I have to use Windows at work, and it’d be great to know if a solution exists), you have to log out of the current user, log in as the administrative user, make the change, and log back in again as the original user.

Same deal for Mac OS X. You can’t just open Finder as an administrator. In fact, because Mac OS X has a better security implementation (it uses sudo, same as Ubuntu) than XP’s, even an administrator can’t modify system files through Finder. You have to enable the root account and use its Finder, or make changes through the terminal.

Desktop Linux has one up on Windows and Mac in this regard, but it’s still not completely smooth. If you know you’re going to modify a system file, you can launch your file browser window with root (or administrator) privileges even within a regular account. If you have Konqueror plugins, Nautilus scripts, or Thunar custom actions, you can right-click on a system file and edit it as root.

To be fully smooth, file browsers should have drag-and-drop authentication.

In other words, a Ubuntu user, for example, who happens to be in the admin group (meaning that she can sudo to temporarily gain root privileges for a particular task) can drag a file to a system folder and instead of getting the old Access denied: You do not own that folder warning, she gets an authentication dialogue:

• Modify system folder (you will be prompted for a password)
• Do not modify the system folder

Likewise, when someone who is in the admin group opens a system file and tries to save it, instead of getting Unable to save: you are not the owner of the file, he’ll get an authentication dialogue to make changes to the system file.

That’s how it should go. It’s smooth. It makes up for you forgetting to open the file with root privileges. It allows you to back out if you don’t want to modify the system file. And it wouldn’t appear for users who aren’t sudoers—they would get the Access denied error message.

More importantly, it wouldn’t frustrate the hell out of new users who then “yell” on the forums “What does it mean I’m not the owner of the file? I’m the only person using this computer! I own every file on the system!!! Why can’t I be root?” Or, worse yet, when told she’s not the owner of the system files, the new user might attempt to change ownership of the system files, thus rendering her installation non-functional.