"ефективності прав" ??? де ви таке формулювання знайшли?

Може бо видалення файлу з каталогу то операція запису відносно каталогу а не файлу?

Це ви фактичні права доступу (effective permissions) так переклали?
Для видалення файла треба внести зміни у каталог, що його містить, а у нього самого не треба. Тому порушення немає.

це вже буде інший файл

Можна створити новий файл з тим самим ім'ям що було у файлу який було видалено перед тим.

Єдиний нюанс, посилання. Справа у тому, що каталог то просто набір жорстких посилань на файли. Файл існує доти поки існує хоч одне жорстке посилання на нього.
Фіча, яка вдається з розділами коли видаляєш їх і створюючи заново повертаєш вміст не спрацьовує з файлами, так як при створенні нового файлу він створюється навмання (за новим розміщенням) і на нього створюється нове жорстке посилання.

Ну ще маленький, що якщо відкрити файл то ви отримуєте вміст жорсткого посилання, тож поки не закриєте файл можна читати файл який було видалено після відкриття його вами.

Якщо файл будете лише читати то вам треба тоді використовувати формати файлів з цифровим підписом (який перевірятимете вже у скрипті) чи окремо накладати цифрові підписи, бо в усіх інших випадках того гарантувати не можна якщо користувач буде мати достатньо прав щоб здійснити підміну файлу. Наприклад, у вас є conf.xml файл налаштувань, ви можете підписати даний файл ключем пара від якого вшита в скрипт, та відбиток зберегти в conf.xml.sign, при запуску скрипта той має обов'язково перевірити наявність підпису та відповідність вмісту до підпису і лиш тоді вичитувати вміст conf.xml для своєї роботи.

Якщо ж у користувача досить обмеженні права і не недостатньо для створення ситуації коли можливе здійснення підміни, то перевіряти права від кореня на відсутність прав достатніх для здійснення підміни. Наприклад, якщо у користувача немає можливості виконувати операції від root (чи іншого користувача) то перевіряти щоб від кореня до самого файлу були виставленні права так щоб без прав root (чи іншого користувача) він не міг змінити файли та теки.

Всі криптоалгоритми мають певний рівень стійкості, тобто час який потрібний на їх подолання, то може бути від секунд до тисяч років, але навіть цей показник не враховує ріст продуктивності заліза, тому ще варто окремо робити прогноз щодо зростання продуктивності та її доступність та на нього коригувати поточну стійкість алгоритму.

Щодо захисту скрипта, то тут вже окрема історія. Є таке поняття як ланцюг довіри. Де є точка з якої починається довіра.

Для прикладу, як функціонують системи ЕЦП: є наприклад мін'юст, у якого є кореневий сервер який той береже і на ньому підпис, яким він підписує сертифікати підписів центрів сертифікації, які в свою чергу підписують підписи вашої організації. То поки можна довіряти мін'юсту ви можете довіряти всьому ланцюгу і маючи лише вбудованим в софт пару до підпису мін'юста ви можете перевірити весь ланцюг: у центра сертифікації взявши сертифікат на підпис що перевіряєте та перевірити що він виданий ним, взявши вбудований сертифікат мін'юста перевірити підпис яким підписує центр сертифікації сертифікати на підписи що видає. Але якщо підпис мін'юста скомпроментований то скомпрометований весь ланцюг.

Ще один приклад, принцип Secure Boot. Є в uefi/bios вбудований сертифікат виробника процесора, яким той перевіряє сертифікат до підпису розробника award (чи іншого розробника uefi/bios) яким перевіряється цілісність bios/uefi якщо підпис справній, за допомогою сертифікату award перевіряється підпис розробника MS (чи іншої ОС) яким підписано заванажувач ОС і відповідно перевіряє цілісність завантажувача якщо підпис дійсний, за допомогою сертифікату підпису MS перевіряється підпис релізу ОС і якщо той дійсний перевіряється цілісність ядра та інших захищених компонентів включно зі сховищем сертифікатів підписів за допомогою яких перевіряються підписи вендорів (розробників драйверів) та розробників програмного забезпечення які потрібні для перевірки цілісность їх та якщо треба наступні рівні підписів якими можуть бути захищенні деякі компоненти.