This could be done by PolicyKit, but don't know what it would take on Nautilus side to be supported.
CC-ing David.

Alex blogged something about it here

http://blogs.gnome.org/alexl/2007/11/23/file-operations-in-nautilus-gio-and-adventures-in-the-land-of-policykit/

I'm up for implementing this we will need to hash out how to do it. I think the bulk of the work is in writing a gio extension and landing that in gvfs. Then things like gedit can take advantage of it too, ideally without code changes, if you try to edit e.g. /etc/fstab.

Alex, you had some more concrete ideas about this? (Ideally a step-wise plan/recipe)

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

what's the situation now? is this a gnome 2.22 stuff or 2.24?

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

This is 2.24+ stuff, as 2.22 is already out and UI frozen.

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

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

bug 538249 also indirectly asked for this feature.

My dream is that Linux will become the most saught after OS.  Unless something like this bug is implemented, it will never happen.

Non-technical users don't want to use Linux because of the extra overhead it takes to do, what should be, simple tasks.  I myself get frustrated with it.

I know we can do better.  I may be wrong, but I think this bug is high priority.

Is there some status on this issue ?

Or is there somewhere on gnome's wiki a description on how to implement it.
I'm a newbie in gnome programming but used to C programming and i'm willing to start working on this bug.

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

Why is this targeted to "File and folder operations"? it should be on GIO. If GIO supports this, every software which use GIO will benefit of this without changes

With GIO I intended GVFS, sorry

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

I agree with Nicolo. (if I understand what he meant about GVFS) This should be done for any operation where the user doesn't have the necessary permissions. (i.e when editing a file from gedit and trying to save it, the user should be asked to authenticate if saving it fails because of permissions.)
So implementing a solution just for nautilus will feel like a hack.

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

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

My idea was adding a simple "New Root Window" to the "Files" menu in nautilus. Then you could at least paste and edit files without using the terminal. I noticed problems when cutting files from the root instance and pasting them in the standard instance of nautilus but other than that it worked just fine. A possible stepping stone? Four years..

Edit: in the "File" menu of nautilus..

(In reply to comment #19)
> My idea was adding a simple "New Root Window" to the "Files" menu in nautilus.
> Then you could at least paste and edit files without using the terminal. I
> noticed problems when cutting files from the root instance and pasting them in
> the standard instance of nautilus but other than that it worked just fine. A
> possible stepping stone? Four years..

This is quite a challenge to implement it properly, and as explained in this bug report, it involves implementing PolicyKit support in GIO/GVfs. I mean, launching the nautilus process with root permissions is *not* a viable option :)

I agree with Cosimo.

I would like to be prompted for a password (similar to OSX) when the file operation fails.

The user will still experience a problem when she forgets to open a root window before performing the file operation(s). What i do as a workaround is to run (i.e: sudo nautilus <path>)  and then redo the file operations I did before.... 
It would be excellent if apps like gedit could also make use of this so when I edit a configuration file I don't have to run "sudo gedit blah.txt" from the terminal.

sudo nautilus Is "New Root Window". I said it could be a stepping stone since this bug is four years old. I did read and understand this thread before commenting.

I'm sure that your understanding of this thread is not in question, but we must be careful not to succumb to the urge to create a workaround instead of a proper solution for this problem. 
It would be better to wait another 4 years and have a proper solution. We don't want the gnome dev team to loose whatever sense of urgency there is for this problem because a workaround now exists.

I understand. I'm actially glad this feature has already been reported. I'm just going to wait for this. In the end it should work as you described earlier - you edit a root file with gedit or nautilus or whatever and you just get to type the password and be done.
I have my hdd encrypted using luks and when i mount it using nautilus it prompts for my root password and mounts. That is the proper solution.

Ah crap, wrong again. Can i edit? I mean when i mount a hdd that needs root permission nautilus just promts and mounts. Nvm the luks thingy.

BTW: I think the reason this bug isn't maybe considered high priority (proof: 4 years and waiting) is that the average Joe doesn't really edit files outside his home directory often or ever. 

Yet, there are more common use cases that the average Joe might encounter more often that might give this bug a higher priority. 
Examples: 
In your use case of mounting encrypted hdds.
OR 
The use cases where files in the home dir (or on mounted removable USB hdds) have "funny" permissions (or set as READ-ONLY etc) on them that the current user does not have the necessary permissions to edit/delete at the time.

Make that 7 years. Perfectionism is the enemy of good.

Alex: Not sure how the last comment is helpful, especially as it might not be "perfectionism" of someone here but simply missing manpower?
Are you interested in working on fixing this bug? That would be great.

I worked on a first implementation at the Boston Summit for this, which can be found here: https://git.gnome.org/browse/gvfs/log/?h=wip/cosimoc/admin

I want to try the backend. What is necessary to make this working? I got:
Error: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action org.gtk.vfs.file-operations is not registered
(sorry I do not have many experiences with polkit)

Could you provide more info? Are there any plans to integrate this in GNOME Files?
 
Alex, you were also on the summit, do you have some comments?

I have few cosmetic nitpicks for the code if it is planned to be pushed:

@@ -85,7 +85,7 @@ check_permission (GVfsBackendAdmin *self,
   GDBusMethodInvocation *invocation = dbus_job->invocation;
   GDBusConnection *connection = g_dbus_method_invocation_get_connection (invocation);
   GCredentials *credentials = g_dbus_connection_get_peer_credentials (connection);
+// It would be nice to move declarations up into the beginning of funtions in the whole file to be consistent with rest of gvfs...
   pid_t pid = g_credentials_get_unix_pid (credentials, &error);
   if (error != NULL)
     {
@@ -198,6 +198,7 @@ do_close_write (GVfsBackend *backend,
     }
 
   g_vfs_job_succeeded (job);
+// It would be nice to use common function for the previous several lines...
 }
 
 static void
@@ -241,6 +242,7 @@ do_append_to (GVfsBackend *backend,
   GFile *file = g_file_new_for_path (filename);
   GFileOutputStream *stream = g_file_append_to (file, flags,
                                                 job->cancellable, &error);
+// It would be nice to use common function for create/append/replace and just put the previous lines in switch...
   g_object_unref (file);
 
   if (error != NULL)
@@ -255,6 +257,7 @@ do_append_to (GVfsBackend *backend,
   /* Seek to the end of the file */
   g_seekable_seek (seekable, 0, G_SEEK_END,
                    job->cancellable, &error);
+// Why is this needed?
   if (error != NULL)
     {
       g_object_unref (stream);
@@ -619,6 +622,7 @@ do_query_fs_info (GVfsBackend *backend,
                  const char *filename,
                  GFileInfo *info,
                  GFileAttributeMatcher *attribute_matcher)
+// Please do not use tabs.
 {
   GVfsBackendAdmin *self = G_VFS_BACKEND_ADMIN (backend);
   GVfsJob *job = G_VFS_JOB (query_info_job);
@@ -632,6 +636,7 @@ do_query_fs_info (GVfsBackend *backend,
   GFileInfo *real_info = g_file_query_filesystem_info
     (file, attributes,
      job->cancellable, &error);
+// Wrong indentation...
   g_object_unref (file);
   g_free (attributes);
 
@@ -765,6 +770,7 @@ do_set_display_name (GVfsBackend *backend,
   char *dirname, *new_path;
   dirname = g_path_get_dirname (filename);
   new_path = g_build_filename (dirname, display_name, NULL);
+// Use g_file_get_path instead?
 
   g_vfs_job_set_display_name_set_new_path (display_name_job, new_path);
   g_vfs_job_succeeded (job);
@@ -1005,6 +1011,7 @@ g_vfs_backend_admin_init (GVfsBackendAdmin *self)
 static void
 acquire_caps (uid_t uid)
 {
+// Caps might be set using setcap for the binary (e.g. in gvfs.spec)...
   struct __user_cap_header_struct hdr;
   struct __user_cap_data_struct data;

There are also some warning when building which needs to be fixed...

http://www.webupd8.org/2015/03/how-to-run-gedit-and-nautilus-as-root.html

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

Hi Ondrej,

Sorry for taking so long to reply - I put this project on the backburner for a bit, but now I would like to try and merge this for GNOME 3.22. 

(In reply to Ondrej Holy from comment #31)
> I want to try the backend. What is necessary to make this working? I got:
> Error: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action
> org.gtk.vfs.file-operations is not registered
> (sorry I do not have many experiences with polkit)

You will need to install the polkit policy file in the same prefix of the policykit helper. It's a bit tricky to make it work with a gvfs jhbuild, but assuming you don't have policykit installed in jhbuild too, I can get it working like this:
- copy daemon/org.gtk.vfs.file-operations.policy into /usr/share/polkit-1/actions and daemon/org.gtk.vfs.file-operations.rules into /usr/share/polkit-1/rules
- restart the polkit daemon with systemctl
- launch the helper using pkexec with the full install path in the same way the admin mount spec would, e.g. like this: pkexec ~/jhbuild/install/libexec/gvfsd-admin --address $DBUS_SESSION_BUS_ADDRESS
- I can now do gvfs-ls admin:/// and I'll get a polkit prompt

> Could you provide more info? Are there any plans to integrate this in GNOME
> Files?

Yeah, we plan to add a feature such as "Open location as Adminstrator" to Files once this lands.

> Alex, you were also on the summit, do you have some comments?
> 
> I have few cosmetic nitpicks for the code if it is planned to be pushed:

Thanks for the comments, I pushed another iteration to https://git.gnome.org/browse/gvfs/log/?h=wip/cosimoc/admin that should address them.

Hello. Since gksu hasn't been updated since 2009 and is no longer supported on Ubuntu, we Ubuntu users (in particular) want PolicyKit integration in Gedit (and Nautilus, I suppose). I know that simply asking for it won't make it happen, but I was hoping to link the bug URL on Launchpad into this bug report, can someone do that for me? Thanks Cecchi for volunteering to work on this!

https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/1433657

(In reply to ads200002 from comment #35)
> is no longer supported on Ubuntu

Sorry, 'is no longer recommended for use (and hasn't been for a while)', not 'supported' was a bit strong (wish I could edit comments on here).

ads200002, I have it on my TODO for GNOME 3.22, but I didn't have time to take a look at it yet, but don't worry, we are at the beginning of development cycle for the upcoming GNOME 3.22!

Cosimo, thanks for the updated codes...

Thanks again for the updated codes and hints how to test it. I have finally found some time to test it, sorry for the delay. It looks overall good to me and it seems it works pretty well, but obviously some fixes for Nautilus will be needed...

diff --git a/daemon/admin.mount.in b/daemon/admin.mount.in
index 0996a9e..0d5e8ed 100644
--- a/daemon/admin.mount.in
+++ b/daemon/admin.mount.in
@@ -1,4 +1,5 @@
 [Mount]
 Type=admin
-Exec=/bin/sh -c 'pkexec @libexecdir@/gvfsd-admin --address "$@" $DBUS_SESSION_BUS_ADDRESS'
+Exec=/bin/sh -c 'pkexec @libexecdir@/gvfsd-admin --spawner "$@" --address $DBUS_SESSION_BUS_ADDRESS'
+# I have to change the previous line as you see to make it work. Otherwise I see "Error connecting to D-Bus: Key/Value pair 0, '1.126', in address element ':1.126' does not contain an equal sign (g-io-error-quark, 13)" when automounting, because "--spawner" is lost somehow and also "--address" is on the wrong place....
 AutoMount=true
diff --git a/daemon/gvfsbackendadmin.c b/daemon/gvfsbackendadmin.c
index 39a4b9e..db81bf2 100644
--- a/daemon/gvfsbackendadmin.c
+++ b/daemon/gvfsbackendadmin.c
@@ -189,7 +189,11 @@ do_query_info (GVfsBackend *backend,
     (real_info, G_FILE_ATTRIBUTE_ACCESS_CAN_READ, TRUE);
   g_file_info_set_attribute_boolean
     (real_info, G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE, TRUE);
-
+  g_file_info_set_attribute_boolean
+    (real_info, G_FILE_ATTRIBUTE_ACCESS_CAN_DELETE, TRUE);
+  g_file_info_set_attribute_boolean
+    (real_info, G_FILE_ATTRIBUTE_ACCESS_CAN_RENAME, TRUE);
+// You should add also _CAN_DELETE and _CAN_RENAME, however e.g. Nautilus needs some changes probably, because it seems it honor unix mode instead...
   g_file_info_copy_into (real_info, info);
   g_object_unref (real_info);
 
@@ -391,9 +395,9 @@ do_open_for_read (GVfsBackend        *backend,
     goto out;
 
   g_vfs_job_open_for_read_set_handle (open_read_job, stream);
-  g_vfs_job_open_for_read_set_can_seek
-    (open_read_job,
-     g_seekable_can_seek (G_SEEKABLE (stream)));
+  g_vfs_job_open_for_read_set_can_seek (open_read_job,
+                                        g_seekable_can_seek (G_SEEKABLE (stream)));
+// I prefer such indentation regardless of line length, this applies on other places also, but it is not crucial...
 
  out:
   complete_job (job, error);

Thanks for picking this up again. I pushed a few fixes for your comments in the branch now (and rebased it to master).

Thanks for a quick update, I see that you used Exec= path as I proposed in Comment 38. Would be nice to figure out why "--spawner" is lost and needs to be explicitly specified, because g_spawn_command_line_async is already called with "--spawner":
https://git.gnome.org/browse/gvfs/tree/daemon/mount.c#n445

Otherwise I think it is ready to push and I look forward to seeing admin mode in Nautilus :-)

(In reply to Ondrej Holy from comment #40)
> Thanks for a quick update, I see that you used Exec= path as I proposed in
> Comment 38. Would be nice to figure out why "--spawner" is lost and needs to
> be explicitly specified, because g_spawn_command_line_async is already
> called with "--spawner":
> https://git.gnome.org/browse/gvfs/tree/daemon/mount.c#n445

Hmm, I wonder if this could be g_option_context_parse() accidentally stripping out the option then. Perhaps we could just copy the arguments before passing it to g_option_context_parse()? Can you test if that works?

Hmm, I made some tests and realized that the problem is in shell, because "$@" doesn't include $0...

So we can add some dummy zero argument (e.g. with name of binary), which would be better than what we have currently:
-Exec=/bin/sh -c 'pkexec @libexecdir@/gvfsd-admin --spawner "$@" --address $DBUS_SESSION_BUS_ADDRESS'
+Exec=/bin/sh -c 'pkexec @libexecdir@/gvfsd-admin "$@" --address $DBUS_SESSION_BUS_ADDRESS' gvfsd-admin 

Otherwise we can lost --debug and add --spawner twice if spawned with enabled debugging currently...

Or do you have better idea?

Oh, I see. You could also add "$0" inside the shell command though, can't you?
Something like:
Exec=/bin/sh -c 'pkexec @libexecdir@/gvfsd-admin "$0" "$@" --address $DBUS_SESSION_BUS_ADDRESS'

It works also, but "/bin/sh" is used as zero argument if any arguments aren't specified, see:

$ /bin/sh -c 'echo "$0" "$@"' arg
arg
$ /bin/sh -c 'echo "$0" "$@"' # THIS IS WRONG
/bin/sh
$ /bin/sh -c 'echo "$@"' dummy arg
arg
$ /bin/sh -c 'echo "$@"' dummy

AFAIK it is always called with additional arguments, however it would be probably better to use some dummy argument for sure...

Agreed... I amended the commit in the branch and added a comment too.

Thanks. Automounting works properly for me currently :-) So I think it is more-or-less ready to push, or do you have some concerns against it? I expect that some additional patches may be needed for the Nautilus integration, but it can be done later. I suppose that any Nautilus-related patches for this aren't available yet, are they? 

On the other hand, I realized that it works only with GIO-based applications because FUSE path is not provided for user invisible shares. This is a drawback and I am afraid it is a quite common use-case to open files in non-GIO-based applications...

Probably some hack may be added in order to provide fuse path also for admin backend and let it user invisible. The problem is that once you provide a password for the fuse daemon, then all other applications might access files over it, which isn't probably acceptable. However, the pid of a real client is passed into some jobs, so we could pass it into all jobs, see set_pid_for_file/get_pid_for_file. Then we can check permission for both of pids if differs (the one from d-bus and the one from job). What do you think?

(In reply to Ondrej Holy from comment #46)
> Thanks. Automounting works properly for me currently :-) So I think it is
> more-or-less ready to push, or do you have some concerns against it? I
> expect that some additional patches may be needed for the Nautilus
> integration, but it can be done later. I suppose that any Nautilus-related
> patches for this aren't available yet, are they? 

Yes, I think this should be merged now regardless of the Nautilus side. Me or Carlos will work on that after this is merged.
 
> On the other hand, I realized that it works only with GIO-based applications
> because FUSE path is not provided for user invisible shares. This is a
> drawback and I am afraid it is a quite common use-case to open files in
> non-GIO-based applications...
> 
> Probably some hack may be added in order to provide fuse path also for admin
> backend and let it user invisible. The problem is that once you provide a
> password for the fuse daemon, then all other applications might access files
> over it, which isn't probably acceptable. However, the pid of a real client
> is passed into some jobs, so we could pass it into all jobs, see
> set_pid_for_file/get_pid_for_file. Then we can check permission for both of
> pids if differs (the one from d-bus and the one from job). What do you think?

I'm not familiar enough with the FUSE code in gvfs to really evaluate whether what you describe is feasible at all, but I remember that when we talked about it with Alexander, we explicitly disabled FUSE access for this backend.

I think this is still very useful without it, and would like to merge it regardless, as I probably won't have time to investigate the FUSE feature myself (and it can be built on top of this).

Ok, please push it into master, ideally before the Monday release :-)

Thank you! I now pushed it to master.