"Apply Permissions to Enclosed Files" button doesn't work

[Atalanttore]

 * Nemo version (nemo --version) 5.2.4
 * Distribution - (Mint 17.2, Arch, Fedora 25, etc...) Linux Mint 2.3
 * 64 bit

Issue The changed owner and group of a folder are not applied to the files it encloses when you click the Apply Permissions to Enclosed Files button.

Steps to reproduce

1. Open Nemo with root privileges.
2. Select a folder.
3. Open its context menu.
4. Click on Permissions tab.
5. Change the Owner and the Group from one user to another.
6. Click on the Apply Permissions to Enclosed Files button below.

Expected behaviour All enclosed files (and maybe folders?) belong to the new owner and group.

Actual behaviour All enclosed files and folders still belong to the old owner and group. Clicking the Apply Permissions to Enclosed Files button did not change the permissions.

[Jeremy7701]

Expected behaviour All enclosed files (and maybe folders?) belong to the new owner and group.

Owner and Group are not permissions.

If the "Apply Permissions to Enclosed Files" worked properly, it would only adjust the Read, Write, Execution flags.

Investigate the CLI command chown, which can do what you want - but care is needed if the recursive form is used.

[Atalanttore]

Investigate the CLI command chown, which can do what you want - but care is needed if the recursive form is used.

Hopefully, this is not the only option. I never need CLI commands on Windows 10 in everyday workplace use, and privately with Linux Mint it should be no different, please.

[Jeremy7701]

Changing ownerships is not "everyday workplace use".

How did these folders etc come to be owned by the wrong user?

[smurphos]

Whilst is always nice when the OS works as expected, when it doesn't make it work...this adds a 'Take Ownership' context menu option to nemo when the selection includes items not owned by the user. 4 text files.....

'Take Ownership' nemo action.

~/.local/share/nemo/actions/take_ownership.nemo_action

[Nemo Action]
Name=Take Ownership (Admin)
Comment=Take ownership of %F
Exec=<action_scripts/take_ownership.sh %F>
Icon-Name=system-users-symbolic
Selection=notnone
Extensions=any;
Conditions=exec <action_scripts/check_ownership.sh %F>;
Quote=double
Dependencies=zenity;

~/.local/share/nemo/actions/action_scripts/take_ownership.sh

#!/bin/bash
export SUDO_ASKPASS="$HOME/.local/share/nemo/actions/action_scripts/zenity_askpass.sh"
SUCCESSSTRING="Ownership changed to $USER:$USER -"
COMMAND="sudo -A chown"
for i in "$@"; do
  if [ "$(stat -c %U "$i")" = "$USER" ] ; then
    continue
  fi
  if [ -d "$i" ]; then
    if zenity --question --icon-name=dialog-question --no-wrap --title="Take ownership" --text="Take ownership of directories recursively?"; then
    COMMAND="sudo -A chown -R"
    fi
    break
  fi
done
 for i in "$@"; do
  if stat -c %U "$i" | grep "$USER"; then
    continue
  fi
  eval "$COMMAND $USER:$USER '$i'"
  if [ $? = 1 ]; then
    zenity --info --width=250 --text="Error taking ownership of $i. Try again."
    exit 1
  else
    SUCCESSSTRING+="
    $i"
  fi
done
notify-send "$SUCCESSSTRING"

~/.local/share/nemo/actions/action_scripts/check_ownership.sh

#!/bin/bash
for i in "$@"; do
  if [ "$(stat -c %U "$i")" = "$USER" ] ; then
    RESULT="1"
    continue
  else
    RESULT="0"
    break
  fi
done
exit "$RESULT"

~/.local/share/nemo/actions/action_scripts/zenity_askpass.sh

#!/bin/bash
zenity --password --title="Authenticate"

[Jeremy7701]

@smurphos That is very impressive!

A possible problem -- $USER needs to have a sudoers entry... Also, the group is set to the same value as $USER - but that could be easily fixed (if desired).

[Atalanttore]

Changing ownerships is not "everyday workplace use".

How did these folders etc come to be owned by the wrong user?

The files and folders were created by one user for another user (with a different user account).

[smurphos]

I use it for much the same use case as Atalanttore - files in a 'data' partition shared with multiple users - all users are members of each others groups, but files do end up being owned by the user who (last) saved or created them, and this does complicate some things (backup primarily) so I just wanted a quick GUI way to take directories and files under my user and groups ownership. And a user who is not a sudoer should definitely not be able to take ownership of any file....

[LinuxOnTheDesktop]

I am left unclear about what Nemo's permissions window is supposed to do; and it still, on Mint 21, cannot do something that I wish it to do - though I think it gives the false impression that it can - namely, set permissions to items within a selected directory.

[taltamir]

whether or not changing owner and group is a standard daily occurance or not, the gui explicitly states it does a thing, and then does not do the thing it tells you it does. which is a bug.

also, this bug is wider in scope than what the original post stated. this is not limited to changing owner and group. any and all changes in permissions do nothing when you click on apply permissions to enclosed files button.

currently as of 21.3 opening nemo ordinarily as a user (without admin permissions) nemo does not allow me to change owner (as in, there is no drop down menu for it). however nemo does allow me to change:

1. group
2. read/write/execute flags for files and folders for owner, group, and others.
3. special flags "set user ID" "set group ID" and "sticky"

I just tested changing every single allowed property. when using nemo to modify permissions on an individual file. everything works. when clicking on "apply permissions to enclosed files". nothing works. that button is simply nonfunctional

[Jeremy7701]

If a user could change a file/folder to some other user owner there would be no point in having a permissions system. This is why only root (or admin in the GUI) can change the owner. So not a bug - its an important feature.

The apply "permissions to enclosed files" is actually quite complicated. Assuming it worked:- You obviously won't be able to escalate the permissions of a file, unless you own it - so the operation might fail for some files. Is "apply permissions to enclosed files" meant to replace existing permissions or be an additive operation? Do you really want all files in a directory to have exactly the same permissions?

Since it's such an indefinite thing, you might be better served by chmod in the CLI.

[LinuxOnTheDesktop]

@Jeremy7701 : it seems to me that the fundamental point made by taltamir can be rendered as the following deduction.

1. The window at issue offers to do something that it does not. (Premiss.)
2. If a window offers to do something that it does not do, then that is a bug. (Premiss.)
3. The window at issue is buggy. (Inference from 1, 2.)

The deduction is valid. That is, it contains no inference that contravenes the laws of logic. So if one rejects the argument (thinks the argument valid but unsound) then one must show one or more of the premisses to be false. Yet, both 1 and 2 seem true.

[Jeremy7701]

There are two issues:-

1. (Not a bug) nemo does not allow a user to change the owner of a file or directory, unless you are a root or admin user.
2. The offer to apply "permissions to enclosed files" for a directory is a bug since it does nothing - even if you are a root user.

[Atalanttore]

I am amazed and at the same time shocked that the laws of logic have to be used to justify the problem of a GUI that is misleading for the user.

[taltamir]

If a user could change a file/folder to some other user owner there would be no point in having a permissions system. This is why only root (or admin in the GUI) can change the owner. So not a bug - its an important feature. (Not a bug) nemo does not allow a user to change the owner of a file or directory, unless you are a root or admin user.

@Jeremy7701 you are misreading what people are saying. Nobody is asking for this. please reread my post. I never suggested that the goal is to have nemo ignore/bypass permission restrictions.

Nemo correctly uses chown and chmod on one file at a time. It fails to perform those exact same commands with -R option. this is this bug. this has nothing to do with requesting it to ignore permissions.

Some argued this is intentional. I counter argued that if it is intentional for -R to be disabled in the GUI, then the GUI should not give you that option. Again, this does not in any way shape or form request nemo to bypass permission requirements.

My personal guess is that this bug is caused by nemo is trying to use -r instead of -R when using the recursive button.

I also tested it out and it respects permissions. saying you are forbidden to change files you do not own, and changing files you own. so long as you change one file at the time and thus avoid the -R bug.

[Jeremy7701]

If you want to allow a change of "all enclosed files permissions" on folders, you should analyse all enclosed files to see if you have permission to change each and every one - otherwise the attempt will partially fail. It might be possible to try a chmod +0000 on each file (which would change nothing) as a validation check?

It seems doubtful that nemo would ever attempt a '-R' (recursive) system call - even attempting just a single level for the contents of a directory would require some heavyweight validation.

Maybe someone (not me) would care to replicate this option for enclosed files with a nemo script - perhaps in BASH or whatever to gain an appreciation of the problems involved?

[taltamir]

If you want to allow a change of "all enclosed files permissions" on folders, you should analyse all enclosed files to see if you have permission to change each and every one - otherwise the attempt will partially fail.

only working for files you are permitted to change is the intended results. nobody is asking for it to work on files you do not have permission to change. the issue is that it fails to change files for which you have permission to change.

It seems doubtful that nemo would ever attempt a '-R' (recursive) system call

Nemo literally has a button titled Apply Permissions to Enclosed Files This button is literally meant for applying -R There is literally no other possible reason to have such a button. Also -R is an essential button to have. Of course said button should and does obey onwership rules. only allowing you to change files you own.

[taltamir]

I did a bunch of more testing and managed observe a few interesting things:

1. Apply permissions to enclosed files only changes file permissions and not folder permissions. this is different from chmod -R which changes both file AND folder permissions. subfolders simply cannot be changed via the gui at all, except for one at a time. you must use a terminal and do something like chmod 774 ./testperms

2. when you click apply permissions to enclosed files, it goes in recursively through all files in all subfolders and STRIPS permissions based on what you picked in "file permissions" in the gui. note it only strips permissions and cannot add any. if your current permissions are 700 and you want to set it to 770, you can do it one file at a time, or you can use the terminal. the "apply permissions to enclosed files" does not work. but if your current permissions are 774 and you want to change it to 700 then the GUI can do it for you... but only for the files and not for the folders. meaning the the terminal is still the superior method of doing it.

3. while it is applying a mask to existing files. it is NOT using umask on the folder in question. umask ./permtest changes the permissions of future files created in the folder permtest but does not change the permissions of current files. while using the button apply permissions to enclosed files applies a mask to the current files and has no effect on future files created in the folder.

Ideal fix:

• button apply permissions to enclosed files should be renamed to apply permissions to enclosed files and folders
• use chmod -R for said application. this makes this feature actually useful, and make it work the way users expect it to work. while not introducing any risk whatsoever. (sine the user could have easily used a terminal to execute that same command. with identical results that fully respect file ownership)

non ideal fix:

• apply permissions to enclosed files should be renamed to mask file permissions to enclosed files this fixes the fact that the users are told nemo is doing a thing (applying permissions) when it is in fact doing something completely different (masking permissions)

[Jeremy7701]

I believe there's some misunderstanding here. You would never run a change recursively - there is nothing to stop you doing it to /home and causing great destruction. Most folders have exec permissions set; most files don't. They have different meanings. If you run chmod from the CLI, you would expect to be capable of sorting out any errors.

umask is not applicable here - it is not a folder level attribute. Hence, "has no effect on future files created in the folder."

[taltamir]

I believe there's some misunderstanding here. You would never run a change recursively - there is nothing to stop you doing it to /home and causing great destruction. Most folders have exec permissions set; most files don't. They have different meanings.

I have to use -R far far more often than I use chmod without a -R.

as for a person breaking things by using it on /home

1. don't chmod your entire /home directory
2. literally nothing stops a user from using terminal to chmod their entire /home directory. so restricting it in gui is misaimed
3. literally nothing stops you from using gui to change every file in /home to 000 permission set. which would break things.
4. I find it extremely implausible that this is intentional to protect users from themselves.

If you run chmod from the CLI, you would expect to be capable of sorting out any errors.

there are no errors involved in this issue. simply a bug where a button says it does X and instead it does Y. either change what the button does to match what it says, or change what the button says to match what it does. ideally, change both to match the functionality of chmod and do what users actually expect it to do (literally chmod as a user without sudo)

umask is not applicable here - it is not a folder level attribute. Hence, "has no effect on future files created in the folder."

I explicitly said that umask is not being used.

however, the button apply permissions to enclosed files is performing a mask. it just somehow does that mask without using umask. it does not apply the permissions you set, it applies a mask based on the permissions you set in the gui. I am not sure how it does it exactly, I just observed in testing that it does not seem to be using neither umask nor chmod -R current-settings to do so.

my best guess is that nemo is probably running a script to: step 1. list all the files. step 2. calculates the new value for each individual file as if it was masked by the settings you choose in the gui. step 3. individually appliies a chmod to each file to strip permissions based on the provided mask.

[Jeremy7701]

I actually never use the "change the permissions in a directory for all files" and absolutely never do a chmod -R. Something seriously very wrong if you need to do this on a regular basis. You need to know what's in a directory before making these global changes.

I'm sure you're basically right about how nemo alters permissions - except that it will be done in C by issuing library calls.

[alexeymuranov]

2. literally nothing stops a user from using terminal to chmod their entire /home directory. so restricting it in gui is misaimed

I disagree: typing a command in terminal and ticking a checkbox are very different kinds of actions from user perspective. You should not be able to do complex irreversible actions by ticking a checkbox. What would you say about a checkbox that recursively erases a folder?

[Jeremy7701]

I disagree: typing a command in terminal and ticking a checkbox are very different kinds of actions from user perspective. You should not be able to do complex irreversible actions by ticking a checkbox. What would you say about a checkbox that recursively erases a folder?

Just ran a test; two text files in a folder both given 777 permissions, but one file is owned by me, the other by user=nobody Told nemo to remove world-executable permissions from all files in the directory.

Result:- No error/warning message nemo changed the file owned by me; it didn't do anything to nobody's file. nemo should not have allowed me to attempt this operation as it was bound to fail.

[taltamir]

I actually never use the "change the permissions in a directory for all files" and absolutely never do a chmod -R. Something seriously very wrong if you need to do this on a regular basis. You need to know what's in a directory before making these global changes.

-R is only a "global change" if it is used on a global directory. If used on a specific directory containing very specific files then there is nothing global about it. (ex: a /pictures/ folder containing 10,000 pictures and NOTHING else) And I always know exactly what is in a directory before I use -R

For years now I have been dual booting linux and windows. I also have been using NAS for many years, the NAS is connected via SMB because NFS refuses to allow even the slightest measure of actual sane security such as allowing you to set a username and password requirement to connect to a specific share on a the NAS And the files within. note that I am not saying SMB is good. merely that NFS manages to be somehow worse. there is no good option, sadly.

To get back ton task, as files get moved around between windows and linux, or linux and an SMB mounted NAS, those files will end up with wrong permissions and ownership. executing chown and chmod with -R on specific directories containing known files can and does resolve this. I keep my personal files exceedingly well organized so I am always fully aware of exactly what files are in each directory where I perform such an operation.

Performing such operations one file at a time would be utterly insane. whether I am stripping permissions or adding them, -R is essential

In comparison. needing to change one singular file is just a much rarer occurrence. It sometimes crops up, but not often.

Also, there are many other examples or use scenarios out there than differ from my own. But it would be exhaustive to start listing them all. it is very presumptuous and dismissive to insisting people are "using it wrong" for daring to want such basic functionality as recursiveness to actually work.

at the end of the day, mint explicitly allows you to perform changes recursively. it just does not work / contains misleading descriptions and information on what it is actually doing.

[taltamir]

I disagree: typing a command in terminal and ticking a checkbox are very different kinds of actions from user perspective. You should not be able to do complex irreversible actions by ticking a checkbox. What would you say about a checkbox that recursively erases a folder?

Just ran a test; two text files in a folder both given 777 permissions, but one file is owned by me, the other by user=nobody Told nemo to remove world-executable permissions from all files in the directory.

Result:- No error/warning message nemo changed the file owned by me; it didn't do anything to nobody's file. nemo should not have allowed me to attempt this operation as it was bound to fail.

The operation did not fail. It successfully changed every file you own. and ignored every file you do not own. this is exactly the same result you would have gotten from using the command line command.

username@computername:~/testing$ chmod -R 777 ./permtest
chmod: changing permissions of './permtest/t4.txt': Operation not permitted

(note, I would never use 777 for anything other than testing like what we are doing here)

the only different is that the command line command would have warned you about files you are not permitted to change.

Imagine trying to fix permissions on a /pictures/ folder containing 10,000 pictures and being told by nemo that nope, you are not allowed to try because one of the 10,000 pictures files is owned by nobody that is ridiculous.

the fix here is not to make nemo even more broken and incapable of performing operations via gui. the solution is to fix the issue of nemo not providing a warning about excluded files (those you do not own)

[taltamir]

I disagree: typing a command in terminal and ticking a checkbox are very different kinds of actions from user perspective. You should not be able to do complex irreversible actions by ticking a checkbox. What would you say about a checkbox that recursively erases a folder?

is this a joke? I literally can right click on any folder in nemo (barring protected OS folders) and then hit the delete button and it will recursively erase the entire folder.

it will even erase files I do not own held inside folders I do own. try it yourself. create a test folder in ~ create a testfile in that folder then use sudo chown root:root ./filename to change a test file to being owned by root. now right click and select delete that file and/or delete the folder that contains it. it will just work despite you not being root.

also, being able to recursively delete a folder is among the most basic and necessary functionalities of a computer. you literally cannot effectively use a computer without being able to recursively delete folders.

[alexeymuranov]

is this a joke? I literally can right click on any folder in nemo (barring protected OS folders) and then hit the delete button and it will recursively erase the entire folder.

No, this is not a joke, and how is your example relevant?

1. Right clicking and selecting an action is not checking a check box.
2. Moving a folder to trash is a reversible action.
3. Permanent deletion requires a confirmation.

[taltamir]

is this a joke? I literally can right click on any folder in nemo (barring protected OS folders) and then hit the delete button and it will recursively erase the entire folder.

No, this is not a joke, and how is your example relevant?

1. Right clicking and selecting an action is not checking a check box.

The entire LOGIC of your argument was that users should be protected from themselves. Thus, a "very easy" method of "check the box within the gui" should be blocked. While the "scary to noobs" method of "use command line to type commands" should be the only method allowed.

I pointed out to you that you have an even easier method, right click and select delete. Yes, right clicking and clicking an option from the menu that opens is not the exact same thing as checking a box and then clicking apply. But they are both simple GUI operations.

====

This is blatant bug. It says it is doing X, and then does not do anything. Your entire logic for why this bug should not be fixed is that have you some elitist view of the intelligence of users based on whether the use GUI or CLI. And thus that various functionality should be excluded from the GUI to prevent users from breaking things.

This is frankly absurd. Also even if such a backwards opinion was accepted as the design philosophy of the mint team, then they should remove the nonfunctional GUI elements rather than just ignore the bug.

[leigh123linux]

You lot have bored me to the point I've unsubscribed from this garbage.

[alexeymuranov]

Yes, right clicking and clicking an option from the menu that opens is not the exact same thing as checking a box and then clicking apply. But they are both simple GUI operations.

Yes, they are not the same. IMO, checking a checkbox should not have irreversible or difficultly reversible consequences. Can you prove the opposite?

[taltamir]

Yes, they are not the same. IMO, checking a checkbox should not have irreversible or difficultly reversible consequences. Can you prove the opposite?

1. You are asking me to prove the opposite of your silly opinion, how can I prove or disprove your emotions?

2. You flipped the reversibility difficulty of the two operations you are contrasting. You literally are trying to argue that changing permissions is irreversible/hard to reverse. while arguing that deleting files is easily reversible. that is literally the opposite of reality.

changing permissions is neither irreversible nor is it difficult to reverse. deleting files is irreversible as soon as you emptied the trash. You can delete files you do not own via gui via a super easy and simple "right click, click on delete". You can permanently delete them via emptying the trash (2 more clicks), or you could have used shift+del buttons to initiate the permanent delete in the first place.

Meanwhile, checking the boxes for new permissions and then clicking on "apply to all files" button is not irreversible nor hard to reverse. you simply set permissions to what they were before and click on "apply to all files" button again.

3. Your opinion is not congruent with the existing design philosophy of linux mint. Where it absolutely lets you make major changes using the GUI. such as deleting files owned by root or other users. The biggest proof of which is that the button in question exist in the first place. If mint developers adopt your philosophy, then this is still a bug because they need to alter the GUI to remove those nonfunctional features. The GUI should never lie to the user.

[alexeymuranov]

@taltamir,

1. I was not asking you to prove anything, I was asking if you can. The question is whether you have solid arguments, or it is a matter of opinion.

2. Bulk changing permissions if difficult or impossible to reverse if the number of files is large and they had different and unknown to the user permissions. The trash bin is not emptied by ticking a checkbox. I did not say that deleting files is reversible.

[taltamir]

The trash bin is not emptied by ticking a checkbox. I did not say that deleting files is reversible.

you literally brought up reversibility as a counter argument. to defend your claim that procedure A: right click folder > left click "properties" > left click "permissions" > tick box > leftclick "apply to all files" procedure B: right click folder > left click "delete" > right click "trash" > left click "empty trash" > left click "empty trash" are extremely different in terms of difficulty for a noob to execute. and that procedure B is a great way to safeguard a noob user from self harming. while procedure A is completely insufficient (which is why you believe that the GUI should explicitly lie to users and have non functional buttons that do nothing)

Because, you keep on harping about "ticking a box" is "completely different" from deleting a file as a counter argument to my point that the two are equally simple ways for an inexperienced user to cause trouble to himself. And that users are allowed to delete files, they should be allowed to change the permissions of the files the own.

Also, if all you cared about was actually difficulty of the procedure it is easy to add a confirmation window or two in there.

also, the fact that the "apply to all" button EXISTS proves that it is the devs intent to have it exist.

Bulk changing permissions if difficult or impossible to reverse if the number of files is large and they had different and unknown to the user permissions.

that is some serious edge case you are digging into. a user that does not even know what permissions his files should have, then he isn't really losing anything. unless he managed to open nemo using root and is actually applying identical settings to his root folder... which, as mentioned, in that scenario he might as well have just deleted everything. something he could have easily done.

Honestly if we are talking self harm. the easiest thing is to just go click start > click terminal > sudo rm -rf / which is way fewer to self harm compared to either of the procedures I mentioned earlier

[Atalanttore]

and that procedure B is a great way to safeguard a noob user from self harming. while procedure A is completely insufficient (which is why you believe that the GUI should explicitly lie to users and have non functional buttons that do nothing)

As a noob, I find it particularly annoying when pressing a button in a software (or on a device) has no effect and no corresponding explanation is displayed.