Является ли `chown user: user lost + found` вредным?

Недавно я создал зашифрованную файловую систему ( 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
источник

Не все файловые системы имеют каталог lost + found. Например, Ext4, XFS - нет.

— Jornane

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

— Джо

Ответы:

Хороший совет приходит с обоснованием, чтобы вы могли определить, когда он станет плохим советом.

Целью того, lost+foundчтобы быть владельцем root, является то, что независимо от того, чей файл был утерян, он не будет внезапно открыт для всех. Однако в этом случае во всей файловой системе не должно быть ни одного файла *, не принадлежащего pduck; поэтому нет недостатка в lost+foundтом, что pduck не принадлежит.

* исключение экзотических ситуаций, таких как pducking suroot и запуск приложения X. Но если pduck может использовать sudoили тогда suмы ни о чем не говорим, потому что pduck может полностью нарушить безопасность системы.

— Джошуа
источник

lost+found является системным каталогом, и я избегаю вмешательства в права владения и разрешения системных каталогов и файлов.

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

sudo find ...

и оставить lost+foundкак есть {должно / должно быть}.

— sudodus
источник

Да, так думал я, но 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

В каталоге lost + found нет ничего особенного. Это просто обычный каталог, как и любой другой, и он используется только для хранения потерянных файлов / каталогов, найденных во время fsck после сбоя системы или повреждения файловой системы.

Он создается во время mkfs при создании файловой системы и обычно пуст. Единственная причина разрешений по умолчанию состоит в том, чтобы не дать чувствительным файлам стать видимыми для обычных пользователей, если они были обнаружены и восстановлены во время fsck. В современную эпоху редко можно увидеть, как файлы теряются и помещаются в эту папку.

Если он будет удален, я полагаю, что fsck будет воссоздавать его по мере необходимости, если там будут какие-либо файлы, которые нужно поместить туда. Поскольку это файловая система для одного пользователя и одних его данных, при этом нет необходимости скрывать эти данные от посторонних глаз, я не вижу причин, по которым разрешения нельзя было бы изменить, скажем, на 755, чтобы запретить поиск или изменить его. владение. Вполне возможно, что fsck может сбросить свои разрешения в процессе восстановления, но это редкое событие в современной файловой системе, если только нет серьезного аппаратного сбоя.

Что касается простого удаления, я полагаю, что вся паранойя вокруг этого основана на том факте, что fsck лучше всего делать как можно меньше для восстановления данных, но я не думаю, что это действительно имеет большое значение на практике.

— penguin359
источник