Чи шкідливий користувач `chown: користувач втратив + знайдено`?

Нещодавно я створив зашифровану файлову систему ( crypto_LUKS), яка виконує функції $ HOME лише для одного конкретного користувача (тобто я монтую її як /home/pduck). Я також додав відповідний запис, /etc/security/pam_mount.conf.xmlщоб розділ автоматично розшифровувався та монтувався, коли користувач увійшов (і відключився, коли він вийде з системи). Чудово працює.

Оскільки $ HOME є власною файловою системою, у користувача є lost+foundкаталог, що належить root: root. Я знаю, що видалення каталогу - погана ідея, але багато команд (наприклад find) скаржаться на відсутність доступу. Це мене дратує.

З цікавості я видалив каталог і відтворив його з mklost+found(без sudo). Тепер каталог належить pduck: pduck. Це нормально чи важливо, що каталог належить root: root?

— PerlDuck
джерело

Не у всіх файлових системах є втрачений + знайдений каталог. Наприклад, Ext4 робить, наприклад, XFS.

— jornane

Не відповідь, але ви можете просто створити сценарій чи псевдонім для пошуку (бажано з іншим ім’ям), який починається з того, 2>/dev/nullщо замовчує ці повідомлення про помилки. Якщо ви поставите його на початку, то це не завадить будь-яким аргументам, які ви хочете передати, щоб знайти в кожному виклику.

— Джо

Відповіді:

Гарна порада має обґрунтування, щоб ви могли сказати, коли це стане поганою порадою.

Мета lost+foundволодіння коренем полягає в тому, щоб незалежно від того, чий файл він був загублений, він не раптом піддавався всім. Однак у цьому випадку не повинно бути жодного файлу у всій файловій системі *, що не належить pduck; тому немає недоліків lost+foundне володіти пдуком.

* заборона екзотичних ситуацій, таких як pduck suing до root та запуск програми X. Але якщо pduck може використовувати sudoабо suчим ми говоримо ні про що, тому pduck може порушити безпеку системи прямо.

— Джошуа
джерело

lost+found - це системний каталог, і я уникаю посягань на право власності та дозволи на системні каталоги та файли.

Є й інші каталоги (і файли), які findнарікають, якщо я не підвищую дозволи командного рядка, тому я пропоную вам використовувати

sudo find ...

і залиште так, lost+foundяк це {є / повинно бути}.

— судодус
джерело

Так, так подумав я, але OTOH є така mklost+foundкоманда, щоб створити її, і вона створює її з моєї власності. Можливо, це просто жахливо написана команда, яка не перевіряє $UID!=0;-) Крім того, мені не подобається думка про те, що я змушений (більш-менш) використовувати sudoв своєму власному $ HOME.

— PerlDuck

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

— sudodus

Не fsckвкладає файли туди, коли він стикається з "втраченими" файлами? Ідея полягає в тому, що fsckвже є де розмістити файли (замість того, щоб спочатку створити один). Зверніть увагу, що lost+foundзаймає більше місця (16384 байт), ніж звичайний порожній каталог (4096 байт).

— PerlDuck

Так, принаймні, це було початковою метою (подібно до того, що chkdskбуло з втраченими файлами в MSDOS), але я рідко, якщо коли-небудь бачив там якісь дані в Linux. Можливо, журнал може відновити файли там, де вони були раніше, тому їм не потрібно йти lost+found. - До речі, у мене є lost+foundдовідник /home, але не в домашньому довіднику /home/sudodus, тому він мене там не турбує.

— sudodus

Я згоден. І у /homeмене є ще одна l+f(не турбувати мене теж) , так /homeі /home/pduckокремі розділи на моїй машині. Остання зашифрована, перша - ні. Однак, коли це мене дратує занадто сильно, я можу встановити свій $ HOME десь в іншому місці і прив’язати його до мого фактичного $ HOME (як я описав тут , наприклад), щоб повністю позбутися l+fв моєму $ HOME. /// Я видаляю свої коментарі через пару хвилин / годин, щоб уникнути сповіщення про "розширену дискусію ... перехід до чату" .

— PerlDuck

Немає нічого насправді магічного в програмі загубленого + знайденого. Це просто звичайний каталог, як і будь-який інший, і використовується лише для зберігання втрачених файлів / каталогів, знайдених під час fsck після краху системи або пошкодження файлової системи.

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

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

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

— пінгвін359
джерело