Чи є спосіб запобігти видаленню певних файлів із каталогу, що належить користувачеві?

42

Скажімо, у користувача є Directory1, і він містить File1 File2 CantBeDeletedFile Як зробити так, щоб користувач ніколи не дозволив видалити CantBeDeletedFile ?

Якщо я змінити право власності на Directory1 та видалити дозволи на запис, користувачі не зможуть видалити жоден файл. Вони також не зможуть додавати нові файли тощо.

Я просто хочу мати можливість встановити деякі файли, які ніколи не буде видалено.

Більш конкретний опис.

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

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

Якщо для всіх * nix немає загального способу, це FS Linux і ext4.

— бакитн
джерело

40

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

Це повинно працювати на Linux (принаймні). Я припускаю user, що вже є членом групи user. Рішення - змінити право власності Directory1та встановити клейкий біт у каталозі:

chown root:user Directory1
chmod 1775 Directory1

Потім використовуйте:

chown root Directory1/CantBeDeletedFile

Тепер userне вдасться видалити цей файл через клейкий біт¹. userВсе ще в стані додати / видалити свої файли Directory1. Але зауважте, що вони не зможуть видалити, Directory1оскільки вони ніколи не будуть спорожнені.

-
^{1. Коли в каталозі включений клейкий біт, користувачі (крім власника) можуть видаляти лише власні файли всередині каталогу. Це використовується в таких каталогах /tmp, дозволами яких є 1777= rwxrwxrwt.}

— Стефан Гіменес
джерело

Мені теж не подобається, але користувачі - новачки у світі Linux. Якщо вони випадково видаляють запуск, вони починають спам на нашу технічну підтримку :)

— bakytn

Спасибі це працює! Не впевнений, як я буду діяти. З chattr або таким чином. Якщо робити на своєму шляху. Я все ще можу видалити Каталог як корінь. З верхнім рішенням (chattr) навіть root не може видалити папку.

— bakytn

@bakytn: це лише обережність чи ви насправді отримали виклик служби підтримки? Тому що, мабуть, більшість новачків буде надто боятися возитися з файлами, яких вони не знають.

— Лі Лі Раян

@Lie Ryan на 100% впевнений, що вони закликають підтримати. Але так, на даний момент це лише обережність.

— bakytn

Рано чи пізно тренувальні колеса повинні зійти ... і якщо вони не навчилися їздити на велосипеді, аварія стане щось на виду. Я погоджуюсь з відповіддю, ймовірно, доповненою різноманітною он-лайн допомогою та консервованим спамом "Якщо ви" випадково "видалили ThisDesktopFile, спершу перейдіть до найближчої стіни і 3 рази сильно вдарившись головою об неї (на удачу), а потім зробіть cp /here/is/the/master/ThisDesktopFile $HOME. : BOfH "

— фонбранд

63

Зробіть файл незмінним з iатрибутом.

chattr +i file.desktop

див. man chattrдля отримання додаткової інформації.

— Кіт
джерело

8

Я додаю цю примітку, оскільки мені не вдалося вивести її із згаданої сторінки man: chattrпрацює лише у файлових системах ext2 / ext3 / ext4.

— манатура

Це так круто! Це спрацювало! Спасибі пане! Елегантне рішення, але одне обмеження. Навіть root не може видалити ці файли, попередньо не зробивши його змінним. Але це так круто насправді. Не був впевнений, яку відповідь прийняти. Прийняв більш загальний шлях, але менш швидкий

— bakytn

@manatwork він також працює на XFS, принаймні, я думаю, що деякі інші файлові системи також підтримують ці атрибути.

— Руслан

Щоб "скасувати" цю команду, просто виконайтеchattr -i file.desktop

— GreenRaccoon23,

1

Я щойно тестував це на zfs на Linux і він працював. Я хотів запобігти видаленню файлу, який використовується для вказівки програми резервного копіювання baculaігнорувати папку.

— drescherjm

2

Я не думаю, що існує спосіб запобігти видаленню окремого файлу з дозволами файлів Unix, але я можу придумати вирішення проблеми: написати демона, який замінює його, коли він буде видалений. inotify-toolsідеально підходить для подібних речей, якщо ви працюєте в Linux.

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

— Шон Дж. Гофф
джерело

0

Простий

chmod -i filename

якось "захистить" цей файл від видалення.

rm filename
rm: remove write-protected regular file 'filename'?

Ви все одно можете видалити його, але принаймні ви повинні бути досить впевнені в тому, що робите.

— fiatjaf
джерело