Applying Permissions to enclosed files in Nautilus' Folder Properties window doesn't work

[David Raid]

To reproduce, gksudo nautilus to get root permissions, find a folder with files inside. Right click the folder and choose properties, go onto the permissions tab and change the owner and group to something else, eg to ubuntu if root, or root if ubuntu. Click the 'Apply perms to enclosed files' option and then close the window. Wait a bit before closing it if you wish, but when you go into that folder and check the permissions of the files inside, they will not have changed.

I noticed this when copying my firefox profile from my main partition onto my live USB of the daily build.

[Fabio Marconi (fabiomarconi)]

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

[Ken Clive (ken.clive)]

I've confirmed that this also occurs in Precise (12.04, x64). I am quite new to fixing bugs in Ubuntu, but I am willing to give it a shot.

[Sebastien Bacher (seb128)]

@Ken: thanks, contributions are welcome, you might want to engage directly with upstream on https://bugzilla.gnome.org/show_bug.cgi?id=663649, don't hesitate to ask questions if you need guidance or are not sure where to start

[Ken Clive (ken.clive)]

Haven't quite figured this one out yet, since GTK+ is not familiar territory for me. However, I found the code snippet that operates the button: it's the "apply_recursive_clicked" function in nautilus-properties-window.c. The for loop in lines 4344-4371 may be the trouble spot, but I'm not sure:

 /* Advanced mode and execute checkbox: */
 for (l = window->details->permission_buttons; l != NULL; l = l->next) {
  button = l->data;

  if (gtk_toggle_button_get_inconsistent (GTK_TOGGLE_BUTTON (button))) {
   continue;
  }

  active = gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (button));
  p = GPOINTER_TO_INT (g_object_get_data (G_OBJECT (button),
       "permission"));
  is_folder = GPOINTER_TO_INT (g_object_get_data (G_OBJECT (button),
        "is-folder"));
  is_special = GPOINTER_TO_INT (g_object_get_data (G_OBJECT (button),
         "is-special"));

  if (is_folder || is_special) {
   dir_permission_mask |= p;
   if (active) {
    dir_permission |= p;
   }
  }
  if (!is_folder || is_special) {
   file_permission_mask |= p;
   if (active) {
    file_permission |= p;
   }
  }
 }

You can see where is_folder and is_special (which are gboolean variables) are assigned values, integers are being passed into a boolean variable. I'm seeing similar lines of code in other parts of this file, but I'm not sure if this is correct or not.

[shubham sharma (shubham-sha12)]

i am a newbie i want to give it a to fix this bug.Is this bug fixed?

[Ken Clive (ken.clive)]

Shubham,

I am currently working on this issue, and it's a bit complicated because this is a feature that hasn't been implemented into the button yet. I am directly consulting with the nautilus developers upstream to resolve this issue, since I have been familiarizing myself with the nautilus source over the past week in my spare time.

[Ken Clive (ken.clive)]

I have chosen to un-assign myself from fixing this bug. I have gained a lot more insight into how to possibly implement a recursive ownership change function, but am not familiar with the I/O aspect of it (there seems to be a particular timing of pushing and popping jobs involved). Basically, here is how far I've gotten:

1) In src/nautilus-properties-window.c, there exists a function apply_recursive_clicked() that is linked to the "Apply permissions to enclosed files button".

2) There is a for loop near the end of apply_recursive_clicked() that takes the values from the permissions combo boxes and applies them recursively to the contents. Within this loop, the permissions are applied using nautilus_file_set_permissions_recursive(), which is located in libnautilus-private/nautilus-file-operations.c.

3) In nautilus_file_set_permissions_recursive(), a SetPermissionsJob object takes on the permissions values passed to it, but not the owner and group. I added char values for those to the function, but then had to go back to the SetPermissionsJob class definition and add group and owner as parameters (which may not be the optimal way to do this...).

4) What's even more confusing now in nautilus_file_set_permissions_recursive() is the following, after the SetPermissionsJob object receives its values:

if (!nautilus_file_undo_manager_pop_flag ()) {
  job->common.undo_info =
   nautilus_file_undo_info_rec_permissions_new (job->file,
             file_permissions, file_mask,
             dir_permissions, dir_mask);
               }

 g_io_scheduler_push_job (set_permissions_job,
      job,
      NULL,
      0,
      NULL);

I found a nautilus_file_undo_info_rec_permissions_new() in nautilus-file-undo-operations.c, as well as nautilus_file_undo_info_ownership_new(). However, I'm not sure how I would implement nautilus_file_undo_info_ownership_new() since its name suggests that it isn't recursive. I'm not sure where to progress from this point, but I have definitely gotten a lot clearer on how this all could be tied together.

[Sebastien Bacher (seb128)]

@Ken: thanks, could you add this comment on the upstream bug as well? While we have some GNOME hackers working on Ubuntu upstream is probably a better place to share those infos and discuss the work needed in any case since bugzilla comments will reach the people writing nautilus where on launchpad you mostly reach the integration team in Ubuntu

[Ken Clive (ken.clive)]

Sebastien,

OK, I will copy the comment to upstream right now. The nautilus team will know much better how to handle this one.

- Ken.

On Jun 7, 2012, at 2:48 PM, Sebastien Bacher <email address hidden> wrote:

> @Ken: thanks, could you add this comment on the upstream bug as well?
> While we have some GNOME hackers working on Ubuntu upstream is probably
> a better place to share those infos and discuss the work needed in any
> case since bugzilla comments will reach the people writing nautilus
> where on launchpad you mostly reach the integration team in Ubuntu
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/822993
>
> Title:
> Applying Permissions to enclosed files in Nautilus' Folder Properties
> window doesn't work
>
> Status in Nautilus:
> New
> Status in “nautilus” package in Ubuntu:
> Triaged
>
> Bug description:
> To reproduce, gksudo nautilus to get root permissions, find a folder
> with files inside. Right click the folder and choose properties, go
> onto the permissions tab and change the owner and group to something
> else, eg to ubuntu if root, or root if ubuntu. Click the 'Apply perms
> to enclosed files' option and then close the window. Wait a bit before
> closing it if you wish, but when you go into that folder and check the
> permissions of the files inside, they will not have changed.
>
> I noticed this when copying my firefox profile from my main partition
> onto my live USB of the daily build.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nautilus/+bug/822993/+subscriptions

[Carlos (bostoniancarlos)]

May be not a Nautilus problem, Krusader has the equivalent problem. (Right click a directory-->Properties-->Permissions change Group and Others from Forbidden to Can View & Modify Content -->OK and nothing happen as root using gksudo).

May be the problem is deeper.

Thank you.

[Carlos (bostoniancarlos)]

I am under Ubuntu 12.04

[Josue Barrios Rodriguez (jbarrios)]

if the problem it's about permissions, why not use chown and chmod with -R option as background process on apply button?

[Leonardo Donelli (learts92)]

It was never a bug in the first place, just bad design:
https://bugzilla.gnome.org/show_bug.cgi?id=663649#c3
Cosimo Cecchi, Nautilus developer, said:
"Apply permissions to enclosed files" button is only meant to apply *permissions* (as in the values of the "Folder/File Access" comboboxes) recursively, and not group and owner information (and it works in that regard).
The current version of Nautilus has a modified interface that makes more clear that only permission are changed on enclosed files.