4 ms·

It's rm with a trash can that by default is in a terribly insecure location (/tmp is typically world read/writable). EDIT: just tested it, it creates /tmp/grav

It's rm with a trash can that by default is in a terribly insecure location (/tmp is typically world read/writable). EDIT: just tested it, it creates /tmp/graveyard-$USER with 0755.

formerly_proven 2y ago
The XDG trashcan would be a better place, and you'd even be able to restore files using whatever GUI file browser you use: https://specifications.freedesktop.org/trash-spec/latest/ https://specifications.freedesktop.org/trash-spec/latest/
- globular-toast 2y ago
  Before I read this comment I thought "xdg-trash spec" in the README was bashing xdg.
- rozab 2y ago
  It would be nice to know how and why the goals of this supposedly diverge from xdg-trash
leetrout 2y ago
And sometimes mounted to a device with less storage
linkdd 2y ago
[flagged]
osmsucks 2y ago
[flagged]
dathinab 2y ago
That's not quite how things work, file permissions don't magically go way just because they land in tmp, this is only a problem if your file permissions are setup wrongly and implicitly relied on parent folders etc. But then file permissions being "wrong" or relying on the parent folder is the norm... I wonder if it does keep ACLs associated with the file.
- bravetraveler 2y ago
  Take this prior art for example: ~ $ ll -d $HOME/.local/share/Trash drwx------. 5 me me 47 Jan 15 2020 /home/me/.local/share/Trash Home directories and the root they're stored in aren't generally well-protected, trash directories should do so to avoid leaking. Per the XDG spec if this is open, you want sticky bits. More justice (and considerations) here: https://specifications.freedesktop.org/trash-spec/latest/ https://specifications.freedesktop.org/trash-spec/latest/ An interesting challenge or angle to this: space consumption, ownership in a real-world sense (ie: fingerpointing)
eptcyka 2y ago
God forbid `/tmp` is a different filesystem from wherever the original file resided in.
- xk3 2y ago
  which, it usually is... tmpfs
  - bravetraveler 2y ago
    Self-clearing insecure recycle bin, but it's memory safe!!!
    - wongarsu 2y ago
      And if you delete too much the trash folder on tmpfs will fill up to half your available memory. With how terrible linux is with swap, unintentionally deleting a lot of data while doing something memory-intensive may well cause your system to slow to a crawl, forcing you to either sit it out or reboot and lose your recycle bin
      - bravetraveler 2y ago
        Don't forget 'systemd-oomd' who may try to help. Depending on the configuration of your distribution/desktop environment, there's a non-zero chance your whole DE gets whacked. I generally am a fan of 'systemd', but the collection of parts require attention. cgroups and such Absolutely none of this is a concern for this project, though. I just find this-then-that stuff funny
  - adrian_b 2y ago
    Which, until recently, was losing file metadata, like extended attributes (in very old tmpfs versions also the timestamps could have been truncated). Whenever exact file copies are desired, they must not pass through /tmp or through any other place where tmpfs is mounted, unless it is checked that the tmpfs version is new enough to preserve file metadata. (In multi-user computers, it was usual to copy a file through /tmp for copies between users, because that might have been the only place where both users had access.) Older versions of tmpfs did not support any extended attributes, then only certain system attributes were preserved, while all user attributes were deleted. Only one year or two ago tmpfs has been enhanced to preserve most extended attributes, with some size constraints. Many older systems still have tmpfs versions that lose the extended attributes.
irdc 2y ago
This is a good practical example for the less experienced that just because it’s written in rust doesn’t mean it’s magically more secure. Who’s gonna write up the CVE?
imdsm 2y ago
It's a great idea but perhaps needs to be executed a little better. Hoping the op reads these comments as us all just being grumpy sysops but takes the positives from them, and works on rip3 with better system-level safety. And for everyone else, always worth remembering that author could have instead built: . Instead they chose to build something, so let's not shit all over their intent
- butterfly42069 2y ago
  Here here!
- stavros 2y ago
  Not only that, but the comment could have been much better: It could be an issue on GH saying "the default location is insecure, please use ~/.cache" or whatnot.
- keybored 2y ago
  Good point. :) I definitely overanalyze to the point where I program a lot less extracurricular stuff. I admire people with the ability to just do it.
selfmodruntime 2y ago
That is a neat easy challenge for my next CTF.
xyst 2y ago
Author acknowledges how the tmpdir can be a bad default, so that’s why you can change it :) > Graveyard location. > You can see the current graveyard location by running rip graveyard. If you have $XDG_DATA_HOME environment variable set, rip will use $XDG_DATA_HOME/graveyard instead of the $TMPDIR/graveyard-$USER. > If you want to put the graveyard somewhere else (like ~/.local/share/Trash), you have two options, in order of precedence: > Alias rip to rip --graveyard ~/.local/share/Trash > Set the environment variable $RIP_GRAVEYARD to ~/.local/share/Trash. > This can be a good idea because if the graveyard is mounted on an in-memory file system (as /tmp is in Arch Linux), deleting large files can quickly fill up your RAM. It's also much slower to move files across file systems, although the delay should be minimal with an SSD.
- beanjuiceII 2y ago
  >rip is a rust-based rm with a focus on safety, ergonomics, and performance then puts the default trash location in /tmp ? knowing its a bad decision? kinda makes me leery of the rest with this kind of reasoning skills
  - stavros 2y ago
    Yeah, I can't disagree with this, knowing that something is a bad default and still using it isn't fantastic. It would be much better to put the files somewhere else and clear old files whenever rip was run.
- forgotpwd16 2y ago
  >~/.local/share/Trash Kinda bad example since this tool doesn't follow xdg-trash spec per README. Tools that do (such as the file managers from the big DEs) use this directory.
ksynwa 2y ago
Anyone knows how something like GNOME or KDE handles it? I am guessing a directory in user's home should be good enough, right?
mcranmer 1y ago
Maintainer here. This comment is incorrect. rip2 creates the graveyard with 0700, not 0755. That change was one of the reasons for forking from the original rip. Code: https://github.com/MilesCranmer/rip2/blob/6165ed0c692b27f196c02e449a3da179d801ce41/src/lib.rs#L45 https://github.com/MilesCranmer/rip2/blob/6165ed0c692b27f196...

It's rm with a trash can that by default is in a terribly insecure location (/tmp is typically world read/writable). EDIT: just tested it, it creates /tmp/graveyard-$USER with 0755.

formerly_proven 2y ago

The XDG trashcan would be a better place, and you'd even be able to restore files using whatever GUI file browser you use: https://specifications.freedesktop.org/trash-spec/latest/ https://specifications.freedesktop.org/trash-spec/latest/

globular-toast 2y ago
Before I read this comment I thought "xdg-trash spec" in the README was bashing xdg.
rozab 2y ago
It would be nice to know how and why the goals of this supposedly diverge from xdg-trash

leetrout 2y ago

And sometimes mounted to a device with less storage

linkdd 2y ago

[flagged]

osmsucks 2y ago

[flagged]

dathinab 2y ago

That's not quite how things work, file permissions don't magically go way just because they land in tmp, this is only a problem if your file permissions are setup wrongly and implicitly relied on parent folders etc. But then file permissions being "wrong" or relying on the parent folder is the norm... I wonder if it does keep ACLs associated with the file.

bravetraveler 2y ago
Take this prior art for example: ~ $ ll -d $HOME/.local/share/Trash drwx------. 5 me me 47 Jan 15 2020 /home/me/.local/share/Trash Home directories and the root they're stored in aren't generally well-protected, trash directories should do so to avoid leaking. Per the XDG spec if this is open, you want sticky bits. More justice (and considerations) here: https://specifications.freedesktop.org/trash-spec/latest/ https://specifications.freedesktop.org/trash-spec/latest/ An interesting challenge or angle to this: space consumption, ownership in a real-world sense (ie: fingerpointing)

eptcyka 2y ago

God forbid `/tmp` is a different filesystem from wherever the original file resided in.

xk3 2y ago
which, it usually is... tmpfs
- bravetraveler 2y ago
  Self-clearing insecure recycle bin, but it's memory safe!!!
  - wongarsu 2y ago
    And if you delete too much the trash folder on tmpfs will fill up to half your available memory. With how terrible linux is with swap, unintentionally deleting a lot of data while doing something memory-intensive may well cause your system to slow to a crawl, forcing you to either sit it out or reboot and lose your recycle bin
    - bravetraveler 2y ago
      Don't forget 'systemd-oomd' who may try to help. Depending on the configuration of your distribution/desktop environment, there's a non-zero chance your whole DE gets whacked. I generally am a fan of 'systemd', but the collection of parts require attention. cgroups and such Absolutely none of this is a concern for this project, though. I just find this-then-that stuff funny
- adrian_b 2y ago
  Which, until recently, was losing file metadata, like extended attributes (in very old tmpfs versions also the timestamps could have been truncated). Whenever exact file copies are desired, they must not pass through /tmp or through any other place where tmpfs is mounted, unless it is checked that the tmpfs version is new enough to preserve file metadata. (In multi-user computers, it was usual to copy a file through /tmp for copies between users, because that might have been the only place where both users had access.) Older versions of tmpfs did not support any extended attributes, then only certain system attributes were preserved, while all user attributes were deleted. Only one year or two ago tmpfs has been enhanced to preserve most extended attributes, with some size constraints. Many older systems still have tmpfs versions that lose the extended attributes.

irdc 2y ago

This is a good practical example for the less experienced that just because it’s written in rust doesn’t mean it’s magically more secure. Who’s gonna write up the CVE?

imdsm 2y ago

It's a great idea but perhaps needs to be executed a little better. Hoping the op reads these comments as us all just being grumpy sysops but takes the positives from them, and works on rip3 with better system-level safety. And for everyone else, always worth remembering that author could have instead built: . Instead they chose to build something, so let's not shit all over their intent

butterfly42069 2y ago
Here here!
stavros 2y ago
Not only that, but the comment could have been much better: It could be an issue on GH saying "the default location is insecure, please use ~/.cache" or whatnot.
keybored 2y ago
Good point. :) I definitely overanalyze to the point where I program a lot less extracurricular stuff. I admire people with the ability to just do it.

selfmodruntime 2y ago

That is a neat easy challenge for my next CTF.

xyst 2y ago

Author acknowledges how the tmpdir can be a bad default, so that’s why you can change it :) > Graveyard location. > You can see the current graveyard location by running rip graveyard. If you have $XDG_DATA_HOME environment variable set, rip will use $XDG_DATA_HOME/graveyard instead of the $TMPDIR/graveyard-$USER. > If you want to put the graveyard somewhere else (like ~/.local/share/Trash), you have two options, in order of precedence: > Alias rip to rip --graveyard ~/.local/share/Trash > Set the environment variable $RIP_GRAVEYARD to ~/.local/share/Trash. > This can be a good idea because if the graveyard is mounted on an in-memory file system (as /tmp is in Arch Linux), deleting large files can quickly fill up your RAM. It's also much slower to move files across file systems, although the delay should be minimal with an SSD.

beanjuiceII 2y ago
>rip is a rust-based rm with a focus on safety, ergonomics, and performance then puts the default trash location in /tmp ? knowing its a bad decision? kinda makes me leery of the rest with this kind of reasoning skills
- stavros 2y ago
  Yeah, I can't disagree with this, knowing that something is a bad default and still using it isn't fantastic. It would be much better to put the files somewhere else and clear old files whenever rip was run.
forgotpwd16 2y ago
>~/.local/share/Trash Kinda bad example since this tool doesn't follow xdg-trash spec per README. Tools that do (such as the file managers from the big DEs) use this directory.

ksynwa 2y ago

Anyone knows how something like GNOME or KDE handles it? I am guessing a directory in user's home should be good enough, right?

mcranmer 1y ago

Maintainer here. This comment is incorrect. rip2 creates the graveyard with 0700, not 0755. That change was one of the reasons for forking from the original rip. Code: https://github.com/MilesCranmer/rip2/blob/6165ed0c692b27f196c02e449a3da179d801ce41/src/lib.rs#L45 https://github.com/MilesCranmer/rip2/blob/6165ed0c692b27f196...