GNOME Bugzilla – Bug 524199
When password is needed to modify a file, Gedit should ask user to give its password instead of saying "you can't save modifications"
Last modified: 2012-07-30 05:15:08 UTC
Policykit is there to avoid the user to get a dialog box that would say "that can't be done" without offering a workaround (if i'm not mistaken) well i've run Nautilus, and i've opened in Gedit etc/X11/xorg.conf i've made some changes in it and pressed the "save" button (which was active) and i've gotten an error message I think that : either the save button should not be active (at less) either the user should have the possibilty to give the password to be able to save the file (that would be perfect to me) (from https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-March/003681.html ) i'm running Gedit 2.22 within Ubuntu 8.04 beta
I wonder if a more general solution to this problem would be more appropriate, e.g. modifying GnomeVFS, or using something like PLASHs trusted "Open/Save file chooser dialog box". See http://plash.beasts.org/index.html
see that article : http://www.osnews.com/story/19524 "thanks to PolicyKit, Nautilus will actually prompt for the root password if you try to access a restricted location or file, something other operating systems and file managers have been able to do since Citizen Kane came out. Sadly, PolicyKit does not seem to have been integrated fully just yet. If you open as a normal user, say, sources.list, in gedit, edit it around a bit, and try to save it, you cannot. It will not ask you for the root password - it will just simply say "I'm afraid I can't do that", and offer a cancel button. Something to work on for the future."
This bug should at least be confirmed. Gedit is the obvious use case, and should be simple enough to do for most purposes until a more general solution is done elsewhere.
This should indeed be fixed in Gedit, NOT in Nautilus. PolicyKit was invented to eliminate the need for programs to run as root. If Nautilus decides to run Gedit as root by the use of PolicyKit, the actual purpose of PolicyKit has been defeated. It's not a new name for sudo. Gedit should ask PolicyKit for precisely the permissions it needs to complete the task: write permissions for the specific place where the file will be saved. That results in two things: * No elevated permissions for Gedit itself. * No root permissions at all. If all programs do this: * The attack surface is extremely small, because nothing runs at root. * Sudo has no use case anymore, making removal possible which protects the system from malicious escalation to root.
This bug is still relevant for 2.24.x.
This is not a trivial bug to fix. Yes PolicyKit is there, but it requires us to separate the file writing component of gedit and provide it as an external application. As far as I know the way PolicyKit works is that you request a certain application to be executed with certain privileges, and thus we need to externalize the write process. Although we always have wanted to separate the core loading/saving of gedit in a separate library, for now it is tightly integrated with gedit internals. If/when we start separating gedit in several components (frontend/backend) it will be, to some extend, easy to implement this.
It has been said (on this bug even) that it could be implemented in Gvfs. If that is the case, then gedit doesn't have to be modified at all. Gvfs would be the backend you're thinking about. But I don't know how difficult it would be to implement it in gvfs. If that takes years, then the Gnome-experience suffers. Gedit is arguably the application that is used the most with elevated rights, to edit system configuration files.
Any updates? I find the solution of password prompt in the last moment needed perfect for gedit. In case PolicyKit doesn't do it, you could discuss it with PolicyKit developers, as it might be useful for other developers as well, who don't want to have the administrative process separated just for PolicyKit.
The situation really hasn't changed. We still want to see this happening in gvfs so that everything will just be handled transparently from all the applications. You can't put administrative rights on a running process. This works for things like gvfs because they are out of process (the daemons run as separate processes and communicate over dbus). For gedit we would need to split out a separate binary. However, now that we've cleaned up the way we load and save files, we might be able to look into this again. We have some simple classes now, and we could split out a binary just for saving with elevated rights.
Is it a duplicate of bug 352886 ?
Yes. Thanks. *** This bug has been marked as a duplicate of bug 352886 ***