Мої друзі продовжують видаляти мої файли за допомогою терміналу. Тому, будь ласка, допоможіть мені, пояснивши, як зробити пароль для rm
команди.
Мої друзі продовжують видаляти мої файли за допомогою терміналу. Тому, будь ласка, допоможіть мені, пояснивши, як зробити пароль для rm
команди.
Відповіді:
Немає простого способу встановити такий пароль для самої rm
команди, не без безлічі злому коду, який, ймовірно, порушить такі речі, як apt-get
встановлення пакетів та видалення файлів, а також змусить вас ввести пароль тисячу разів або потенційно зірвати доступ до команди людям, яким вона потрібна (як ви, щоб видалити власні файли). Ви можете зробити це за допомогою кількох облікових записів користувачів та наборів дозволів для декількох дозволів та обмеживши доступ до різних розділів даних, наприклад, до домашнього каталогу, щоб вони не могли дістатися до нього.
(Інший варіант - це індивідуальні облікові записи користувачів для кожного користувача, а потім Списки контролю доступу, як це детально описано в іншій відповіді , опублікованій Videonauth )
Ось головна проблема - ви дозволяєте друзям використовувати вашу систему. Це має численні наслідки для безпеки - концепція "кожен, хто має фізичний доступ до коробки, зможе керувати системою та виконувати будь-які завдання" - це мантра безпеки ІТ, тому ви не "ділите" доступ до фізичних систем за винятком довіреного уповноваженого персоналу.
Єдиний справді розумний спосіб зробити це - не надавати друзям доступ до вашого комп'ютера, а надавати їм "спеціалізовану систему" для гостей ", якою вони можуть користуватися, що вам не дуже цікаво про файли. Це найбезпечніший спосіб зберегти ваші файли.
Звичайно, якщо це не варіант, то ваш єдиний дійсно безпечний варіант - налаштувати кілька облікових записів користувачів, по одному для кожного користувача, з різними домашніми папками, і не дозволяти їм отримувати доступ до вашої власної домашньої директорії або доступу до будь-якого дому іншого користувача довідники. А потім зберігайте все, до чого ви не хочете, щоб вони торкалися у вашому домашньому каталозі, і не надайте їм sudo
доступ, root
пароль або надайте їм свій пароль.
Ось як би це зробити:
Скажімо, мене звуть "Foo", і я хочу, щоб друг "Bar", друг, використовував мою систему, але не мав доступу до моїх файлів. Перший крок - заборонити доступ будь-кому, крім мене, до мого домашнього каталогу. Це дозволяє дозволити іншим користувачам не видаляти ваші файли, а також запобігти переслідуванню інших користувачів у вашому домашньому каталозі та перегляді, які типи матеріалів у вашому домашньому каталозі:
chmod 750 /home/Foo
Другий крок - створити обліковий запис користувача для "Бар" (НЕ вводити те, що в дужках нижче, це лише з інформацією). Таким чином, ми можемо переконатися, що він має свій окремий набір прав доступу:
sudo adduser --create-home --user-group --shell /bin/bash Bar
sudo passwd Bar
(set a temporary password - you will not see characters as you type though)
Третій крок є те обмежити їх домашній каталог теж , так що ніхто не може втручатися в їх файли або. Це просто робить речі рівними.
sudo chmod 750 /home/Bar
Вимийте руки, добре змийте їх, а потім повторіть ці кроки для скільки б то не було користувачів у системі. Вони не зможуть отримати доступ до ваших файлів, і оскільки ви не збираєтесь надавати їм права адміністратора, вони не можуть видалити ваші файли, не намагаючись sudo
це зробити - оскільки ви цього не дозволяєте, вони не можуть торкніться ваших речей. І вони також не зможуть переглядати ваші файли, не ставши суперпопулярним, що тут не відбудеться.
ВЖЕ ПАМ’ЯТАЙТЕ ЦЕ: Надаючи комусь фізичний доступ до машини чи доступ взагалі, ви збираєтесь наражати свої файли та дані на небезпеку. Це загальновизнаний факт у світі ІТ-безпеки і той факт, який продовжує діяти. Надання вашим друзям доступу до вашого комп’ютера завжди піддаватиме вашим даним ризик, тому або надайте їм свою власну систему, щоб зіпсуватись, або просто не надайте їм доступ до вашої машини.
Просто примітка про шифрування диска
Хоча шифрування диска працює добре, щоб захистити ваші дані від сторонніх осіб, є обмеження.
Хоча шифрування диска не вирішує цих проблем, воно створює додаткові шари головного болю для актора загрози. Хтось, хто поганий хлопець, може відмовитись, якщо він зашифрований, або він може вас катувати (черга з обов'язкового коміксу XKCD Security ).
Тому, якщо ваша система зашифрована, але ви дозволяєте іншим користувачам користуватися нею, у них є пароль для розшифровки, або ви залишаєте ноутбук розшифрованим, щоб вони могли отримати SSH або мати фізичний доступ. В обох цих випадках це погано.
Однак, якщо ваша система не зашифрована, цей розділ не має для вас релевантності.
apt-get
працюєdpkg
, яка запускає скрипти , які часто використовують rm
. У моєму вікні Xenial cd /var/lib/dpkg/info; grep -P '\brm\b' *inst
виводиться 344 рядки , з яких 333 виглядають як реальні способи використання rm
команди - лише в сценаріях встановлення . grep -P '\brm\b' *rm
показує ще більше у скриптах для видалення (для видалення конфігураційних файлів, а не пакунків).
Це дійсно не може стосуватися rm
команди, оскільки існують прості способи видалення файлів без їх використання . Якщо проблема полягає в тому, що ваші друзі ненавмисно зловживають rm
командою, тоді рішення, які конкретно обмежують використання цієї команди або змушують її працювати по-іншому, можуть допомогти. На противагу цьому, якщо проблема полягає в тому, що ваші друзі навмисно обробляють ваші дані способом, який ви не хочете, тоді вам потрібно здійснити фактичні заходи безпеки , а не рішення, яке зосереджене на самій rm
команді (або будь-якому дискретному наборі команд) збереже вас у безпеці.
Припускаючи, що ваші друзі знають, що ви не хочете, щоб вони видаляли ваші файли, є дві можливості:
Вони могли робити це спеціально. У цьому випадку ваші друзі навмисно видаляють ваші файли, і ви навіть не можете довіряти їм, щоб спробувати виконати ваші побажання щодо того, як вони поводяться з вашими даними під час використання вашого комп'ютера. Єдине рішення цієї проблеми - використання фактично ефективного заходу безпеки , як детально пояснив Томас Уорд . Найчастіше найкращий такий захід - це утримати їх від використання комп'ютера. Але змушення їх використовувати власні облікові записи користувачів може забезпечити певний захист.
Вони могли це зробити помилково. У цьому випадку ваші друзі надзвичайно схильні до нещасних випадків, і вони продовжують виконувати rm
команди, які б хотіли, щоб їх не було. Вони хочуть з повагою ставитися до вас і до ваших даних, але насправді погано роблять це на практиці, оскільки вони продовжують виконувати неправильну команду, видаляючи неправильний файл ... або щось подібне. Хоча було б добре повірити, що саме це і відбувається, я застерігаю вас від того, щоб припустити, що люди, які продовжують видаляти ваші дані після того, як ви сказали їм припинити, діють без недоброї волі.
Крім того, навіть якщо їхні наміри хороші, надання їм окремих облікових записів користувачів все ще є найбільш нерозумним способом запобігти видаленню файлів, окрім того, що вони не дозволяють користуватися вашим комп'ютером.
Якщо ситуація насправді №2 - ваші друзі не намагаються видалити ваші файли, а просто потребують допомоги, щоб їх випадково не видалити, і єдиний спосіб, коли вони випадково їх видаляють, - це ненавмисне неправильне використання невеликої кількості команд (наприклад rm
) що у них виникають особливі проблеми при правильному використанні - тоді методи у відповіді Videonauth можуть бути корисними. Але ви повинні розуміти , що вони не є заходами безпеки, оскільки команда тільки один з багатьох простих способів для видалення файлів . Детальніше дивіться нижче.rm
Я рекомендую вам запитати себе: "Чи в основному моя ситуація така, як ніби я, а не інші люди, які користуються моїм комп'ютером, використовували rm
неправильно?"
Якщо відповідь - ні , це питання безпеки інформації, і вам потрібно не допустити, щоб ваші друзі могли використовувати ваш обліковий запис користувача. Якщо відповідь " так" , ви можете використовувати ті самі підходи, які ви використовували, якщо ви зловживаєте rm
:
rm file
file
Але навіть якщо ваші друзі не намагаються зробити щось не так, вам все-таки слід подумати про те, щоб вони могли використовувати свої окремі облікові записи користувачів . Це все-таки вирішить проблему - ті ж заходи безпеки, що захищають дані від навмисного знищення, захистять її і від ненавмисного знищення. Навіть без зловмисних намірів, якщо хтось продовжує робити щось, чого ви не хочете, щоб вони це робили, ви не можете довіряти їм утримуватися від цього.
rm
підказки перед видаленням може допомогти запобігти деякі помилки.Для того, щоб допомогти людям уникнути випадкового видалення файлів з rm
, ви можете зробити оболонки псевдонім , який на самому ділі працює . Передача прапора викликає спонукання користувача до видалення кожного файлу (див. ).rm
rm -i
-i
rm
man rm
Ви можете зробити це (для свого облікового запису користувача), додавши alias rm='rm -i'
у свій файл .bash_aliases
чи .bashrc
файл. Дивіться це питання і що один для деталей. Це почне діяти для ваших нещодавно відкритих башмаків.
Це не забезпечує фактичної безпеки і не є надійною у запобіганні помилок, оскільки:
/bin/rm
або скасовуючи його ( unalias rm
).rm
не буде запущено -i
.rm
(як це стосується підходу Videonauth - див. Нижче).Але якщо вам не потрібна реальна безпека (див. Вище), то це може бути шлях. У порівнянні з підходом запобігання друзям використовувати надану системою rm
команду:
Дозвіл rm
на rm -i
менш ефективний для запобігання помилок - поки вони не перейдуть до використання іншої техніки для видалення файлів. У цей момент утримання їх від використання rm
буде абсолютно неефективним, навіть якщо вони не намагаються зробити щось не так, оскільки, імовірно, вони будуть використовувати unlink
(або будь-яку з безлічі інших команд, що видаляють файл) з однаковою бездумністю.
З іншого боку, оскільки розширення псевдоніму відбувається лише в деяких ситуаціях - грубо кажучи, звичайне інтерактивне використання оболонки - ваші друзі можуть подумати, що їм буде запропоновано, коли вони насправді не підкажуть (тому що команда в сценарій, наприклад, або виданий з іншої оболонки). У шляху Відеонаута немає цієї проблеми, що є об'єктивною перевагою цього методу над alias rm='rm -i'
.
Коли сценарій працює, якщо він не написаний навмисно для використання псевдонімів, ваші псевдоніми в ньому не розширюються. Це означає, що злучення rm
з rm -i
великою ймовірністю нічого не порушить. Це об'єктивна перевага alias rm='rm -i'
.
rm
не може зробити нічого, що не могла зробити інша абсолютно звичайна програма.Тут немає нічого особливого rm
. Це зручний та самодокументований спосіб видалення файлів, тому обмеження доступу до нього ризикує зламати численні сценарії, які покладаються на нього. Але далеко не єдиний спосіб видалення файлів - це просто звичайна програма.
Кілька команд виконують певну задачу, яку обмежений користувач (не- root ) не може виконати, не виконуючи їх. Наприклад, sudo
дозволяє запускати програми як інший користувач після перевірки, щоб переконатися, що ви можете це зробити. passwd
редагує базу даних, де зберігаються паролі користувачів, але дозволяє лише змінити власний пароль (якщо ви не root, і в такому випадку ви можете змінити пароль будь-кого).
/usr/bin/sudo
і /usr/bin/passwd
може це зробити, тому що у них встановлено встановлений біт , як показано, s
що з’являється у крайньому лівому стовпчику при запуску ls -l
:
ek@Io:~$ type -a sudo passwd rm
sudo is /usr/bin/sudo
passwd is /usr/bin/passwd
rm is /bin/rm
ek@Io:~$ ls -l /usr/bin/sudo /usr/bin/passwd /bin/rm
-rwxr-xr-x 1 root root 60272 Feb 18 2016 /bin/rm
-rwsr-xr-x 1 root root 54256 Mar 29 2016 /usr/bin/passwd
-rwsr-xr-x 1 root root 136808 Aug 17 09:20 /usr/bin/sudo
Зверніть увагу , що /bin/rm
не має s
: його права доступу -rwxr-xr-x
, в той час як /usr/bin/passwd
і /usr/bin/so
мати -rwsr-xr-x
замість цього. Це робить так, що незалежно від того, хто працює passwd
або sudo
він фактично працює як користувач root, оскільки root є власником виконуваного файлу. (Існує також біт setgid, який при встановленні призводить до запуску виконуваних файлів із груповою ідентифікацією власника групи, а не з особою абонента.)
За винятком будь-яких уразливостей безпеки, які ще не були виявлені (або які були виявлені, але ще не виправлені), sudo
і passwd
є безпечними, оскільки ці утиліти дуже ретельно записані, щоб вони могли робити лише те, що абонент повинен бути дозволений зробити.
/bin/rm
не працює таким чином. Це не налаштовано, тому що цього не потрібно. Дозволи в каталозі (а іноді і дозволи на файли ) контролюють, які файли користувач може видалити, і для цього їм не потрібно ставати root. Щоб бути абсолютно зрозумілим, будь ласка, ніколи не вмикайте встановлений бітrm
. Наслідки для безпеки були б згубними, оскільки тоді, незалежно від того, хто працює rm
, це немов би рут керував ним! (Утиліти люблять sudo
і passwd
перевіряють, хто насправді працює ними, і переконайтеся, що щось дозволено, перш ніж це робити; rm
чи не робить цього.)
Перевірка, чи встановлений біт setuid (або setgid) встановлений у виконаному файлі, підкаже, якщо обмеження того, хто його може запустити, має шанс покращити безпеку. Виконавчі файли, які не встановлені (або setgid), не мають особливого статусу, і кожен може просто скопіювати їх і запустити копію, принести власну копію з іншої машини, написати сценарій або програму, яка робить те саме, або використовувати ще одна програма для цього.
rm
Очевидний спосіб видалити файл без rm
Ubuntu - перейти до його місця в браузері графічних файлів (Nautilus, якщо ви використовуєте Unity або GNOME Shell) та видалити файл. Існують також численні команди, за допомогою яких можна видалити файл із терміналу, не використовуючи жодного разу rm
.
Наприклад, щоб видалити файл, викликаний foo.txt
у поточному каталозі, цього досягнуть наступні команди, які працюють поза вікном Ubuntu та не потребують доступу до нього rm
. (Просто для впевненості , після вилучення я протестував їх на мінімальній системі 16.04, встановленій лише стандартними системними утилітами /bin/rm
.)
unlink foo.txt
busybox rm foo.txt
perl -e 'unlink("foo.txt")'
python3 -c 'import os; os.remove("foo.txt")'
( python
замість python3
старих версій)Цей список, звичайно, ніде не є повним. Повний список таких команд неможливий. Запобігання видаленню файлів є однією з речей, для якої існують окремі облікові записи користувачів та дозволи на використання файлів і каталогів. Вони дуже добре працюють, щоб не допустити цього. Навпаки, зміна rm
команди (щоб зробити її потрібно паролем, або будь-яким іншим способом) або обмеження доступу, щоб rm
взагалі не перешкоджати цьому.
rm
«s -I
варіант. Це вимагає лише для видалення 4 або більше файлів або для рекурсивного видалення. Таким чином, ви не звикли завжди використовувати -f
, \rm
щоб уникнути розширення псевдоніму або введення тексту, y
не читаючи. Але це все одно позбавить вас від поганих помилок, де ви повернетесь до того, як ви мали намір, або ваш глобус відповідатиме багатьом файлам.
mv foo.txt /tmp/.gone
потім перезавантажити, відкинувши tmpfs, що створював резервну копію /tmp
. Або просто використати mv
для перейменування декількох файлів на одне ім’я, так що залишився лише останній. Або просто приховати файли, перейменувавши їх незрозумілими іменами. Як зазначається в першій частині цієї відповіді, якщо ви намагаєтесь захиститись від злоби, а не некомпетентності, вам потрібно просто заблокувати людей зі свого облікового запису.
Ви можете змінити дозволи для /bin/rm
команди за допомогою наступного рядка, що не дозволить виконувати її без доступу sudo:
sudo chmod 750 /bin/rm
Це спеціально заважає їм використовувати rm
команду, надану системою. Ви повинні знати, що це не заважає їм видаляти файли іншими способами.
Щоб також запобігти їх використанню rmdir
команди, що є загальним способом видалення каталогів, ви можете встановити дозволи таким же чином на його виконуваному шляху:
sudo chmod 750 /bin/rmdir
Нагадайте, що ви також можете використовувати ці команди лише з правами sudo.
Для того, щоб змінити його назад , якщо вам не подобається це чи виникають інші проблеми , використовувати 755
дляchmod
Як зазначав @muru, вищесказане - дуже грубе рішення і може навіть порушити системні сервіси, які не працюють на кореневому рахунку. Тому я додаю сюди ще один варіант, використовуючи ACL (списки контролю доступу), щоб зробити те саме, і, ймовірно, набагато безпечніше ( добре читати, а ви можете пропустити включну частину, тому що ACL зазвичай встановлено в системах Ubuntu сьогодні):
Так що робити те саме, що було вище для користувачів, яких ви хочете заблокувати
sudo setfacl -m u:<user-name>:- /bin/rm /bin/rmdir
Просто замініть <user-name>
фактичні імена користувачів, які ви хочете запобігти використанню файлів.
Як і у випадку chmod
, використовуючи setfacl -m
для запобігання запуску конкретних користувачів rm
і rmdir
застосовується лише до цих команд, що надаються системою. Це не заважає їм видаляти ваші файли та папки в Nautilus або використовувати інші термінальні команди.
Пояснення:
-m
прапор означає , що для зміни файлів ACL.u
користувач. Він може мати такі значення u
для користувача, g
для групи та o
для всіх інших<user-name>
може містити фактичне ім’я користувача або ім’я групи відповідно до того, що ви хочете змінити. Для встановлення загальних змін ви залишаєте це порожнім.-
можемо також містити наступні літери r
для дозволу на читання, w
для дозволу на запис та x
для виконання.sudo setfacl -m u:<username>:- /bin/rm /bin/rmdir
, ІІРК. Ви можете протестувати ACL зgetfacl /bin/rm /bin/rmdir
rm
. Рішення, яке тут надав Videonauth, є можливим способом допомогти схильним користувачам припинити видалення речей, але це не забезпечує фактичної безпеки (що може бути нормально, якщо друзі ОП навмисно не намагаються підривати бажання ОП) . Videonauth: Я пропоную відредагувати цю публікацію, щоб вона чітко пояснила, що вона фактично не заважає людям видаляти файли, оскільки для цього їм не потрібна rm
команда. (Я утримуюсь від її редагування самостійно, якщо ви цього не хочете сказати.)
rm
команду.
Це дуже проста відповідь і зупинить когось випадково, використовуючи команду rm, не вводячи пароль. Це не є безпечним рішенням, і ви повинні використовувати деякі альтернативні пропозиції в інших відповідях.
Однак ви можете використовувати псевдонім, щоб змінити спосіб поведінки команди rm. Спробуйте:
alias rm="sudo -l >/dev/null && rm"
Це робиться, коли хтось вводить команду rm, він виконує команду sudo -l. Ця команда змушує користувача ввести свій пароль. Якщо вони зрозуміли це право, він перелічує їхні привілеї (ми відкидаємо цей вихід) і виходимо зі статусом 0, якщо вони помиляються, він існує з помилкою.
Потім ми слідуємо команді sudo з "&&", яка виходить з наступної команди - у цьому випадку "rm", тільки якщо попередня команда закінчується зі статусом 0 - тобто вони отримали правильний пароль.
Щоб зробити це постійним, включіть команду псевдонім у ~/.bashrc
.
Зауважте, це дуже легко перемогти (наприклад, вони можуть просто набрати /bin/rm
.
Я написав сценарій для захисту паролем, rm
як запитував ОП, але також вніс редагування, щоб запобігти випадковому видаленню:
Редагувати: 5 березня 2017 р. - Змініть метод перевірки, чи працює у терміналі.
Використовуйте gksu gedit /usr/local/bin/rm
та копіюйте в цих рядках:
#!/bin/bash
tty -s;
if [ "0" == "$?" ]; then Terminal="Y"; else Terminal="N"; fi
if [ $Terminal == "Y" ] ; then
# Running from terminal don't allow delete of / or /toplevel directory even if sudo
for i in ${@:1}
do
# Skip options -i -r -v -d
if [[ ${i:0:1} != "-" ]] ; then
# if parameter doesn't begin with '-' it's file or directory, so get real path.
fullname=$(realpath "$i" 2>&1) # No error messages if file doens't exist
# We must have at least two `/` in the full path
levels=$(echo "$fullname" | tr -cd '/' | wc -c)
if (( $levels == 1 )); then # Test for 1, will be zero when file doesn't exist.
echo "Attempting to remove top level directory '$fullname'"
echo "Use 'sudo /bin/rm $@' instead."
exit 1 # error
fi
fi
done
fi
if [[ $(id -u) != 0 ]]; then # Only non-root processes enter password (ie "sudo rm ..." is ok)
if [ $Terminal == "Y" ] ; then
# Only running from a terminal needs password (ie not cron)
# log rm usage to /var/log/syslog
PARENT_COMMAND="$(ps -o comm= $PPID)"
logger "$PARENT_COMMAND"" - rm command was used on file: ""$fullname"
# Get password
Password=$(zenity --password --title="Password for rm")
encryptPassword=$(echo -n "$Password" | md5sum)
echo "md5sum: $encryptPassword" # Comment out after viewing one time and updating line below.
if [[ "$encryptPassword" != "d2c30dc65e59558c852ea30b7338abbe -" ]]; then
echo "Invalid password!"
exit 1
fi
fi # non-terminals can't enter password.
fi # root doesn't need to enter password.
# Call REAL rm command with parameters passed to this wrapper sript
/bin/rm "$@"
exit 0
Змініть пароль "WE2U" на все, що вам подобається, і збережіть файл.
rm
сценарій як виконуванийПозначити новий rm
сценарій як виконуваний за допомогою:
sudo chmod +x /usr/local/bin/rm
Якщо пароль не WE2U , при першому запуску скрипту ви отримаєте "недійсний пароль" і відобразиться ключ шифрування для введеного пароля. Скопіюйте та вставте цей ключ шифрування з терміналу в сценарій. Потім прокоментуйте рядок із відлунням, яке відображало ключ шифрування на терміналі.
Оскільки шлях /usr/local/bin
у списку вище, ніж називається /bin
наша команда rm
. Після отримання дійсного пароля він закликає /bin/rm
зробити справжнє видалення.
Як зазначив Томас Уорд в іншій відповіді, якщо ви робите це, sudo apt-get install ...
вам можуть попросити пароль тисячу разів. Сценарій перевіряє, чи sudo
використовується, і не запитує пароль. Крім того, якщо rm
дзвонити з програми GUI, пароль не потрібно.
Сценарій викликів logger
для запису кожного разу rm
був викликаний вручну за допомогою терміналу. Використання команд записується до /var/log/syslog
.
Іншою альтернативою було б створити резервні копії будь-яких важливих файлів у каталозі, до якого некористувальні користувачі не мають доступу. Ви можете використовувати rsync
або unison
синхронізувати їх автоматично, просто переконайтеся, що принаймні одна директорія на шляху до місця резервного копіювання належить корінь та режим 700. Хоча це призведе до отримання двох копій усіх файлів. Було б безпечніше просто створити гостьового користувача для їх використання, за винятком того, що вам потрібно пам’ятати, щоб завжди блокувати або виходити з системи, перш ніж подавати їм комп'ютер або залишати його без нагляду.
Не пряма відповідь на питання, яке ви шукаєте, але:
Якщо ваші друзі видаляють ваші файли за допомогою rm
команди, то або ваші друзі або некомпетентні, ривками, або вони банають бафф, які намагаються навчити вас не залишати свої сеанси вхідними та без нагляду. У всіх випадках рішення те саме: не залишайте свій сеанс увімкненим та без нагляду .
Це має перевагу в тому, що не потрібно пам’ятати про внесення спеціальних змін у систему під час оновлення або отримання нової системи, а також запобігає використанню сценаріїв та інших речей, які покладаються на команди, які поводяться так, як очікувалося, відмовляються непередбачуваними способами.
Він також має перевагу в тому, щоб зупинити "друзів" переходити до наступного кроку. Чи захочете ви також "захистити паролем" mv
команду, якщо вони вирішать перемістити ваші файли до / dev / null, коли виявлять, що просте видалення не робить те, що вони хочуть? Коли ви в такій грі, єдиний виграшний хід - це не грати.
У мене є аналогічна можливість, яку я планував. На файловому сервері, якщо в основному сховищі фотографій можна записати, Somone в сім'ї (менш технічна чи випадково) може щось видалити, випадково перетягніть в gui, який переміщує каталог, або перезапись оригіналу з відредагованою версією, а не перейменуванням .
Я зрозумів, що можу захиститись від цього, не роблячи дозволів непридатними для всіх інших. ZFS робить періодичні знімки, щоб будь-яке випадкове видалення чи перезапис можна було змінити. (На відміну від резервної копії, знімок легкий та копіюється, тому він не збільшує використання вашої пам’яті.)
ZFS є рідним для FreeBSD. У Linux є btrfs, який також має знімки.
Дуже нерозумне вирішення дуже дурного питання.
Якщо ви не хочете chmod
rm
, rmdir
або mv
(для mv filename /dev/null
) або використання списків ACL, ви можете створити користувача манекена з паролем ніхто крім вас НЕ знає і псевдонім кожну команду sudo [user]
, а потім зробити псевдоніми для кожної команди , що ваші друзі не знають . Таким чином, коли ваші друзі наберуть rm
систему, вони запропонують їм ввести пароль (але, якщо ви вгадаєте, що пароль невідомий, буде записано невдалу спробу), і ви все одно можете просто набрати rmalias
або все, що завгодно, фактично видалити файли.
Або ви просто можете створити гостьовий обліковий запис, який не має доступу до домашнього каталогу.
sudo [user]
іdummy user
Якщо ви хочете захистити паролем rm, рішенням буде зробити обгортку для rm, яка потребує кореневих привілеїв, і попросити пароль в іншому випадку. (ПРИМІТКА. Ця обгортка може піти, коли пакет Coreutils буде оновлено або перевстановлено.) Також врахуйте, що це забезпечує лише rm, є ще багато, багато інших способів видалення файлу.
Відкрийте термінал і станьте root. Потім запустіть, sudo mv /bin/rm /bin/rmold
щоб перемістити старий rm в інше місце.
Тепер біжи sudo nano /bin/rm
щоб створити обгортку.
У Нано введіть таке:
#!/bin/bash
/bin/rmold "$@"
exit "$?"
Потім утримуйте CTRL
та натисніть, X
щоб вийти. Натисніть, Y
коли з'явиться запит, а потім натисніть, ENTER
щоб зберегти файл.
Нарешті, нам потрібно надати цьому відповідні дозволи:
sudo chmod a+x /bin/rm
І ось ти йдеш.
$@
=> "$@"
. Ось, що ви пропонуєте, це дуже небезпечна версія оригінальної та безпечної rm
: що робити, якщо є файл з назвою foo -i -r *
( -i
доданий для захисту невинних користувачів)?
"
цитування, $@
як говорить @xhienne, я б закликав вас чітко попередити читачів, що це зовсім не забезпечує безпеку, оскільки є багато способів видалити файл. Одне - зателефонувати rmold
, але існує безліч інших способів, про які йдеться в інших відповідях та коментарях до них. (Вже тоді це виникне проблема, яка rm
буде відчувати, що він видаляє файли як поточний користувач - він називається без sudo
, а нормальний rm
працює як абонент - але це робить як root! Якщо вони нещодавно sudo
редагували, вони виграли " не помічайте, що вони можуть видаляти системні файли, навіть якщо вони знають про зміну.)