`sudo trash` still has no permission about trash-cli HOT 6 OPEN

This behavior is intentional, although, should be better documented.

See: https://github.com/sindresorhus/macos-trash/blob/6f8bf84ff488d3fd64559e632281af184e023191/Sources/trash/main.swift#L6-L7 And the issue that triggered it: sindresorhus/macos-trash#2

If running as sudo, we still want to move it to the users trash and not the root user's trash which is not visible. The problem is that we just call a system API to move the contents to the trash, so the only way to choose the trash directory is to change the permissions of the whole process.

Maybe we could downgrade the permissions of the directory while being sudo, then downgrade the permissions of the process, and then trash it?

from trash-cli.

Maybe we could downgrade the permissions of the directory while being sudo

Not sure if this has to be done recursively.

from trash-cli.

The problem is that we just call a system API to move the contents to the trash

The main advantage of that API is that it is supposed to enable the "Put back" option in Finder, but that doesn't actually work, and after several years Apple doesn't seem likely to ever fix it.

So, on macOS, it makes sense IMO to just ditch the API and move files directly to the trash folder. Some simple logic can take care of naming conflicts, and a bit more logic can allow for a CLI equivalent of Finder's Put Back functionality. Here's a tool I wrote that does those: https://github.com/russelldavis/trash101

from trash-cli.

@russelldavis How the Trash works is an implementation detail and could change in any macOS update. The main advantage is not the "Put back" option in Finder, even though that is (would be 🤷‍♂️) a nice bonus. The main advantage is that it trashes quickly, predictably, and safely. I don't really see the usefulness of "put back" on the command-line, since I would have to remember the original path or know the trash path.

from trash-cli.

Thanks for following up.

I didn't make this clear in my original comment (apologies), but my suggestion to move files directly to the trash would fix this sudo issue -- so I don't think it's off-topic.

If this issue didn't exist, I'd agree with you on using the API. But being unable to trash files with sudo is a non-trivial shortcoming, and AFAICT, there's no good way to fix this issue while continuing to use the API. Responding to an idea from above:

Maybe we could downgrade the permissions of the directory while being sudo, then downgrade the permissions of the process, and then trash it?

This would result in the file(s) in the trash having downgraded (loosened) permissions, which would be bad from a security perspective, and inconsistent with what Finder does when trashing such files.

Realistically, the location of the Trash folder is going to be extremely stable, and in the rare event that it does change, there'd be plenty of notice to deal with it. So to me, it's worth the tradeoff to fix this otherwise intractable issue.

from trash-cli.

Also see: sindresorhus/macos-trash#11

from trash-cli.