Недавно я создал зашифрованную файловую систему ( crypto_LUKS), которая служит в качестве $ HOME только для одного конкретного пользователя (т.е. я его монтирую как /home/pduck). Я также добавил соответствующую запись, /etc/security/pam_mount.conf.xmlчтобы раздел автоматически расшифровывался и монтировался при входе пользователя в систему (и отключался при выходе из системы). Работает отлично.
Поскольку $ HOME сама по себе является файловой системой, у пользователя есть lost+foundкаталог, принадлежащий root: root. Я знаю, что удаление каталога - плохая идея, но многие команды (например find) жалуются на отсутствие доступа. Это меня раздражает.
Из любопытства я удалил каталог и воссоздал его с mklost+found(без sudo). Теперь каталог принадлежит pduck: pduck. Это нормально или важно, чтобы каталог принадлежал пользователю root: root?
источник
2>/dev/nullсимвола, который заставляет замолчать эти сообщения об ошибках. Если вы поместите его в начале, то он не будет мешать любым аргументам, которые вы хотите передать, чтобы найти в каждом вызове.Ответы:
Хороший совет приходит с обоснованием, чтобы вы могли определить, когда он станет плохим советом.
Целью того,
lost+foundчтобы быть владельцем root, является то, что независимо от того, чей файл был утерян, он не будет внезапно открыт для всех. Однако в этом случае во всей файловой системе не должно быть ни одного файла *, не принадлежащего pduck; поэтому нет недостатка вlost+foundтом, что pduck не принадлежит.* исключение экзотических ситуаций, таких как pducking
suroot и запуск приложения X. Но если pduck может использоватьsudoили тогдаsuмы ни о чем не говорим, потому что pduck может полностью нарушить безопасность системы.источник
lost+foundявляется системным каталогом, и я избегаю вмешательства в права владения и разрешения системных каталогов и файлов.Существуют другие каталоги (и файлы), которые вызывают
findжалобы, если я не поднимаю разрешения командной строки, поэтому я предлагаю вам использоватьи оставить
lost+foundкак есть {должно / должно быть}.источник
mklost+foundкоманда, чтобы создать его, и он создает его с моей собственностью. Может быть, это просто ужасно написанная команда, которая не проверяет$UID!=0;-) Кроме того, мне не нравится идея принудительного (более или менее) использованияsudoв моем собственном $ HOME.lost+foundон очень старый, я думаю, с первых дней UNIX, и я не знаю, когда он используется в настоящее время. Но я думаю, что это хорошая общая политика - избегать вмешательства в права владения и разрешения системных каталогов и файлов (если вы действительно не знаете, что может произойти за кулисами).fsckпомещает туда файлы, когда встречает «потерянные» файлы? Идея состоит в том, чтоfsckуже есть место для размещения файлов (вместо того, чтобы сначала создавать файлы). Обратите внимание, что онlost+foundзанимает больше места (16384 байта), чем обычный пустой каталог (4096 байтов).chkdskбыло с потерянными файлами в MSDOS), но я редко когда-либо видел какие-либо данные там в Linux. Возможно, ведение журнала может восстановить файлы там, где они были раньше, поэтому они не должны идтиlost+found. - Кстати, у меня естьlost+foundкаталог в/home, но не в моем домашнем каталоге/home/sudodus, поэтому он меня там не беспокоит./homeменя есть еще одинl+f(не беспокоит меня тоже), потому что/homeи/home/pduckявляются отдельными разделами на моей машине. Последний зашифрован, первый нет. Однако, когда это меня слишком раздражает, я могу смонтировать свой $ HOME где-нибудь еще и связать его с моим фактическим $ HOME (как я описал здесь , например), чтобы полностью избавиться от негоl+fв моем $ HOME. /// Я удалю свои комментарии через пару минут / часов, чтобы избежать предупреждения «расширенное обсуждение… перейти в чат» .В каталоге lost + found нет ничего особенного. Это просто обычный каталог, как и любой другой, и он используется только для хранения потерянных файлов / каталогов, найденных во время fsck после сбоя системы или повреждения файловой системы.
Он создается во время mkfs при создании файловой системы и обычно пуст. Единственная причина разрешений по умолчанию состоит в том, чтобы не дать чувствительным файлам стать видимыми для обычных пользователей, если они были обнаружены и восстановлены во время fsck. В современную эпоху редко можно увидеть, как файлы теряются и помещаются в эту папку.
Если он будет удален, я полагаю, что fsck будет воссоздавать его по мере необходимости, если там будут какие-либо файлы, которые нужно поместить туда. Поскольку это файловая система для одного пользователя и одних его данных, при этом нет необходимости скрывать эти данные от посторонних глаз, я не вижу причин, по которым разрешения нельзя было бы изменить, скажем, на 755, чтобы запретить поиск или изменить его. владение. Вполне возможно, что fsck может сбросить свои разрешения в процессе восстановления, но это редкое событие в современной файловой системе, если только нет серьезного аппаратного сбоя.
Что касается простого удаления, я полагаю, что вся паранойя вокруг этого основана на том факте, что fsck лучше всего делать как можно меньше для восстановления данных, но я не думаю, что это действительно имеет большое значение на практике.
источник