[SOLVED] way to prevent accidental recursive delete in programs?

Aponia71 · 2016-12-28 09:15:17

Hello
I can't find a way to :
- protect some "top" folders from accidental recursive delete
- be able to work (write/delete) in following folder

I want to protect them not only from "rm -Rf" in terminal, but overall from file manager and other programs that handle files operation (filezilla, double commander, ...)
Once in filezilla I accidentally pressed 'delete key' on one of this top folder and lost 1To of files in 2 seconds...

I used to mount each partition of my HD in /media :

/media/
├── BACKUP --> this is sdb1 "top folder"
├── DOWN --> this is sdb2 ..
├── ISOS --> this is sdc1 ..
├── MUSIC ....
├── TEMP ...
└── VIDEO ..

I can set permissions on /media/ and /media/VIDEO/ => this will protect themselves from recursive delete, but all following files and folder inside VIDEO will be deleted in case of "rm -Rf" (terminal or other window program)

I already tried :
- sticky bit => not useful for me
- chattr +i => like permission : protect only the top folder, not the whole hierarchy. If I set "chattr +i -R" (recursive chattr), i can't work , all hierarchy is read-only...
- ACL => no interest since i'm the only user
- safe-rm => not maintained, does not work , but this is quite what I'm looking for

Did anyone have the same needs ?
How do you protect your important files hierarchies without setting read-only on them ? (files backup is not what I want)

Thanks for you help !

_______________________________________________

2017-01-05 : Finally, I found exactly what I need :

cd /media/VIDEO/
find * -type d -print0 | xargs -0 chattr +a

This allow me to add files and create folders in any directories under VIDEO, but prevent from file deletion.

Last edited by Aponia71 (2017-01-05 15:52:22)

ayekat · 2016-12-28 09:31:08

You could transfer ownership to another user (e.g. `media`), and your user would then have read-only access to that hierarchy. If you then want to modify the data in there, you can `su` to that media user and do stuff.

teateawhy · 2016-12-28 21:47:42

You can use a filemanager which moves deleted folders to the trash bin instead of deleting them from the filesystem.
Dolphin will refuse to delete anything bigger than the trash bin, and require a confirmation to delete from the filesystem.
So you can either restore from trash bin, or you can't delete at all.
This will, of course, only work for that filemanager.

Last edited by teateawhy (2016-12-28 22:09:58)

ataraxia · 2016-12-28 21:57:50

This would be hard to ensure, and you would probably keep finding gaps in your coverage, such that some new program would not have the protection. I suggest it would be better to set up good backups for your data, and that way you are protected from this problem and many others you haven't even thought of yet.

Aponia71 · 2016-12-28 22:23:28

Hi all and thanks for your advices
Well... It seems it's difficult to solve
I think I have to apply an "old" way to protect hierarchy :
1) mount sdx1 partition as read-only (in fstab)
2) create a shell script (available in $PATH) with "umount sdx1 / mount sdx1 as read-write"
3) add/delete files in sdx1
4) umount sdx1
5) mount -a

I will also try to mount some top folders with "bind" + "remount read-only" in fstab, and apply the script.
Don't know if it's a good idea ...

ayekat · 2016-12-29 06:51:24

Aponia71 wrote:

I think I have to apply an "old" way to protect hierarchy:

How is that an "old" way? How is that any way? What happens if you accidentally delete your file tree right when your filesystem is in the read-write state?¹ What is wrong with using the file permissions (user/group/others read/write/execute) for what they are there for? Also, what is wrong with keeping backups? Why do you ask for opinions, only to simply ignore them all?

___
¹ Also, if you really want to use this approach, at least use -o remount (otherwise your script will stop working at `umount` if there are open file decriptors in that filesystem).

olive · 2016-12-29 09:08:43

You do not have in mind a very clear logical rules about you want and I think this is the reason you have problems. Permission whatever there are obey logical rules. So let's be clearer:

You say you have a top folder, say "documents" with a whole hierarchy under it. Are you happy to be able to delete all the files and folder under "documents" only to be left with an empty "documents" folder? I guess no, but this satisfies what you claim to want: you have protected the top "documents" folder but you have "worked" with the files and folder in it (i.e. delete them). The sane answer is to render the whole thing read-only but you don't want that either. How can you have the permission to work with files without having the permission to trash them? How do you expect the system to make the difference? It seems you want some kind of true AI to guess what you really want.

One way that could come close to what you want would be to protect directories but not files. You can render the directories immutable but not files under them:

find documents -type d -exec chattr +i {} +

This way you could work (i.e. change the content) with the files under the hierarchy but not add/delete files. Note that you still have the permission to void the contents of all the files with a simple script and I guess you do not want that; for reference the one line script is:

DO NOT TYPE THIS, IT WILL TRASH YOUR DATA! find -type f -exec sh -c 'echo -n "" > "{}"' \;

If you are not happy with the answers here, repost but you should be very clear about what you want. If something can be done in a weird way by a weird script, the same thing could be done accidently. Permission in Linux are supposed to be robust, if you do not have some permission, you can't possibly achieve it unless you have a password or another security credential to bypass/change the permission. There is no permission that prevents you from doing something in a normal way but allows it by a weird purposely written script. The only exception to that rule is a security bug that would need to be patched as fast as possible by the developers.

Last edited by olive (2016-12-29 10:05:08)

Aponia71 · 2016-12-29 10:20:20

ayekat wrote:

Aponia71 wrote:
I think I have to apply an "old" way to protect hierarchy:
How is that an "old" way? How is that any way? What happens if you accidentally delete your file tree right when your filesystem is in the read-write state?¹ What is wrong with using the file permissions (user/group/others read/write/execute) for what they are there for? Also, what is wrong with keeping backups? Why do you ask for opinions, only to simply ignore them all?
___
¹ Also, if you really want to use this approach, at least use -o remount (otherwise your script will stop working at `umount` if there are open file decriptors in that filesystem).

Sorry , it seems I want an "AI", as said Olive, but I know it's not possible. Ayekat, I asked for opinions to be sure I didn't forgot a trial solution, and to see if anyone already had this need.
I will certainly apply one of the solutions given here, but I want to test them on a sample, I have too many files and don't want to do errors.
I think forums can hold such advices, questions, solutions, new tips, ... nothing should be frozen

Aponia71 · 2016-12-29 10:22:01

olive wrote:

...
One way that could come close to what you want would be to protect directories but not files. You can render the directories immutable but not files under them:
find documents -type d -exec chattr +i {} +
This way you could work (i.e. change the content) with the files under the hierarchy but not add/delete files. Note that you still have the permission to void the contents of all the files with a simple script and I guess you do not want that; for reference the one line script is:
...

Olive, thanks for this tip.

Aponia71 · 2017-01-05 15:53:51

Just to say that I solved my problem with another way (see in main post).

Arch Linux

#1 2016-12-28 09:15:17

[SOLVED] way to prevent accidental recursive delete in programs?

#2 2016-12-28 09:31:08

Re: [SOLVED] way to prevent accidental recursive delete in programs?

#3 2016-12-28 21:47:42

Re: [SOLVED] way to prevent accidental recursive delete in programs?

#4 2016-12-28 21:57:50

Re: [SOLVED] way to prevent accidental recursive delete in programs?

#5 2016-12-28 22:23:28

Re: [SOLVED] way to prevent accidental recursive delete in programs?

#6 2016-12-29 06:51:24

Re: [SOLVED] way to prevent accidental recursive delete in programs?

#7 2016-12-29 09:08:43

Re: [SOLVED] way to prevent accidental recursive delete in programs?

#8 2016-12-29 10:20:20

Re: [SOLVED] way to prevent accidental recursive delete in programs?

#9 2016-12-29 10:22:01

Re: [SOLVED] way to prevent accidental recursive delete in programs?

#10 2017-01-05 15:53:51

Re: [SOLVED] way to prevent accidental recursive delete in programs?

Board footer