4 ms·

Is there an alternative to allow scripted destructive actions without the risk of deleting important stuff? Modern OS's will warn you if you try to delete stuf

Is there an alternative to allow scripted destructive actions without the risk of deleting important stuff? Modern OS's will warn you if you try to delete stuff, but you can still ultimately do it anyway, I don't see it as something particular to UNIX. The only similar problem I had was on windows, 98 I guess, I deleted all my files that weren't readonly by fiddling with a .bat script.

Avshalom 11y ago
well there's some safe guard checks you can do to prevent the easy abuses like require an additional flag for rm -rf-ing everything in the root or /home/*/, or across device boundaries as some one said. You can redesign rm so people don't find themselves typing -rf as force of habit. You can have multiple delete commands: mark as overwriteable if need and remove from 'ls -a', actually delete, overwrite sectors with zeros; like we have in guis. You can have a permission system that isn't just "this account can do literally anything" or "this account can't do anything"
- Avshalom 11y ago
  here's a dumb idea off the top of my head: /etc/rmblacklist.conf autopopulated (by the distro) with a list of files (/boot and the actual bootimage for instance) that requires a GNU style long option --nuke to delete. It's still easily scriptable but you'd rarely ever actually need it and requiring a long option would serve as a double check that you meant it when you did. Sure it's still possible to --nuke something due to a bug or negligence but I bet it'd cut down on fatal errors. Plus the user could have their own ~/.rmblacklist.conf to guard against particularly persistent dyslexias. You could even erase the contents entirely if you really think being able to delete root on a whim keeps your kung fu strong.
  - justinlardinois 11y ago
    This isn't a bad idea.
  - nickpsecurity 11y ago
    Good to see you fighting the fight with many sensible ideas. I've been posting this one in most responses as it's pretty simple: https://launchpad.net/safe-rm https://launchpad.net/safe-rm
    - Avshalom 11y ago
      Hah! Beat me to the punch by 5 years.
      - nickpsecurity 11y ago
        Darn, I didnt notice it was that old. Makes situation even worse for UNIX rm defenders. Like when Trusted Xenix eliminated setuid vuln's mostly by clearing setuid bit during a write w/ admin having to manually reset it. Simple shit. Mainstream response? "Just audit all your apps for setuid and be extra careful in..." (sighs)
  - Tiksi 11y ago
    You could just make the file immutable and read only: http://paste.click/qMpmyO http://paste.click/qMpmyO Then remove the immutable flag if needed
whitegrape 11y ago
Have an immutable filesystem, where "deletes" are recoverable by going back in time. At least until you do a scheduled "actual delete" that will reclaim disk space. Another option (though last time I tried it, it didn't work..) is something like libtrash: http://pages.stern.nyu.edu/~marriaga/software/libtrash/ http://pages.stern.nyu.edu/~marriaga/software/libtrash/ Deletes become moves and you can really delete when you like. Practically speaking, if you're quick an 'rm' isn't totally destructive even without backups. There's a good chance your data is still there on the disk, it's just not associated with anything so it could be overridden at any point. Best to mount the disk read only and crawl through the raw bits to find your lost data (I recovered a week's worth of code this way several years ago).
- toomuchtodo 11y ago
  > At least until you do a scheduled "actual delete" that will reclaim disk space. And then you "actual delete" is where the data loss occurs :D
  - Avshalom 11y ago
    Right but if you delete your entire file system there won't be anything to come along and do the "actual delete" so you're safe until some one comes along with a rescue disk or otherwise mounts it to a system that knows how to deal with this. At the very least when you rm important-file.txt instead of importanr-file.txt you have a chance.
  - wruza 10y ago
    Pre-delete would already hide files from apps and services for them to "fail fast", and actual delete would be just "i'm running fine for two days". Of course this implies that active open files should not be pre-deleted on unix at all (at least not by rm process). Even if you delete the entire filesystem with backups, there will be a chance to boot into recovery mode and undelete everything back. We can even go further and apply small-file-versioning on fs level to prevent misconfig accidents in /etc. That's very simple and powerful, I can't tell why it is still not implemented today.
- 11y ago
blakeyrat 11y ago
There's no reason the Recycle Bin couldn't work for scripting languages, except for lazy OS and language developers haven't bothered to wire-it-up.
nickpsecurity 11y ago
https://launchpad.net/safe-rm https://launchpad.net/safe-rm Use something like that with scripting. It really is that easy to protect critical stuff with otherwise easy-to-use rm. UNIX has always been resistant to do stuff like this. However, it's architecture makes it fairly easy for developers to do it themselves. That's to its credit.

Avshalom 11y ago

well there's some safe guard checks you can do to prevent the easy abuses like require an additional flag for rm -rf-ing everything in the root or /home/*/, or across device boundaries as some one said. You can redesign rm so people don't find themselves typing -rf as force of habit. You can have multiple delete commands: mark as overwriteable if need and remove from 'ls -a', actually delete, overwrite sectors with zeros; like we have in guis. You can have a permission system that isn't just "this account can do literally anything" or "this account can't do anything"

Avshalom 11y ago
here's a dumb idea off the top of my head: /etc/rmblacklist.conf autopopulated (by the distro) with a list of files (/boot and the actual bootimage for instance) that requires a GNU style long option --nuke to delete. It's still easily scriptable but you'd rarely ever actually need it and requiring a long option would serve as a double check that you meant it when you did. Sure it's still possible to --nuke something due to a bug or negligence but I bet it'd cut down on fatal errors. Plus the user could have their own ~/.rmblacklist.conf to guard against particularly persistent dyslexias. You could even erase the contents entirely if you really think being able to delete root on a whim keeps your kung fu strong.
- justinlardinois 11y ago
  This isn't a bad idea.
- nickpsecurity 11y ago
  Good to see you fighting the fight with many sensible ideas. I've been posting this one in most responses as it's pretty simple: https://launchpad.net/safe-rm https://launchpad.net/safe-rm
  - Avshalom 11y ago
    Hah! Beat me to the punch by 5 years.
    - nickpsecurity 11y ago
      Darn, I didnt notice it was that old. Makes situation even worse for UNIX rm defenders. Like when Trusted Xenix eliminated setuid vuln's mostly by clearing setuid bit during a write w/ admin having to manually reset it. Simple shit. Mainstream response? "Just audit all your apps for setuid and be extra careful in..." (sighs)
- Tiksi 11y ago
  You could just make the file immutable and read only: http://paste.click/qMpmyO http://paste.click/qMpmyO Then remove the immutable flag if needed

whitegrape 11y ago

Have an immutable filesystem, where "deletes" are recoverable by going back in time. At least until you do a scheduled "actual delete" that will reclaim disk space. Another option (though last time I tried it, it didn't work..) is something like libtrash: http://pages.stern.nyu.edu/~marriaga/software/libtrash/ http://pages.stern.nyu.edu/~marriaga/software/libtrash/ Deletes become moves and you can really delete when you like. Practically speaking, if you're quick an 'rm' isn't totally destructive even without backups. There's a good chance your data is still there on the disk, it's just not associated with anything so it could be overridden at any point. Best to mount the disk read only and crawl through the raw bits to find your lost data (I recovered a week's worth of code this way several years ago).

toomuchtodo 11y ago
> At least until you do a scheduled "actual delete" that will reclaim disk space. And then you "actual delete" is where the data loss occurs :D
- Avshalom 11y ago
  Right but if you delete your entire file system there won't be anything to come along and do the "actual delete" so you're safe until some one comes along with a rescue disk or otherwise mounts it to a system that knows how to deal with this. At the very least when you rm important-file.txt instead of importanr-file.txt you have a chance.
- wruza 10y ago
  Pre-delete would already hide files from apps and services for them to "fail fast", and actual delete would be just "i'm running fine for two days". Of course this implies that active open files should not be pre-deleted on unix at all (at least not by rm process). Even if you delete the entire filesystem with backups, there will be a chance to boot into recovery mode and undelete everything back. We can even go further and apply small-file-versioning on fs level to prevent misconfig accidents in /etc. That's very simple and powerful, I can't tell why it is still not implemented today.
11y ago

blakeyrat 11y ago

There's no reason the Recycle Bin couldn't work for scripting languages, except for lazy OS and language developers haven't bothered to wire-it-up.

nickpsecurity 11y ago

https://launchpad.net/safe-rm https://launchpad.net/safe-rm Use something like that with scripting. It really is that easy to protect critical stuff with otherwise easy-to-use rm. UNIX has always been resistant to do stuff like this. However, it's architecture makes it fairly easy for developers to do it themselves. That's to its credit.