Chown kullanıcı: kullanıcı kayıp + bulundu` zararlı mı?

Son zamanlarda crypto_LUKSsadece belirli bir kullanıcı için $ HOME olarak hizmet veren şifreli bir dosya sistemi ( ) oluşturdum /home/pduck. Ayrıca /etc/security/pam_mount.conf.xmlkullanıcı oturum açtığında (ve oturumu kapattığında bağlantıyı kestiğinde) bölümün otomatik olarak şifresinin çözülmesi ve monte edilmesi için uygun bir giriş ekledim . Harika çalışıyor.

$ HOME kendi başına bir dosya sistemi olduğundan kullanıcının lost+foundroot: root dizinine sahip bir dizini vardır . Bunu biliyorum dizini silme bir olduğunu kötü bir fikir ama birçok komutları (örn find) erişimin olmaması şikayetçi. Bu beni sinirlendiriyor.

Merakımdan dizini çıkardım ve mklost+found(olmadan sudo) yeniden oluşturdum . Şimdi dizin pduck: pduck'e aittir. Tamam mı yoksa dizinin root: root'a sahip olması çok mu önemli?

— PerlDuck
kaynak

Tüm dosya sistemlerinin kayıp + bulunan dizini yoktur. Örneğin Ext4 bunu yapar, XFS bunu yapmaz.

— jornane

Yanıt değil, ancak 2>/dev/nullbu hata mesajlarını susturmakla başlayan (tercihen farklı bir adla) bulmak için bir komut dosyası veya takma ad oluşturabilirsiniz . Başına koyarsanız, her çağrıda bulmak için hangi argümanları bulmak istediğinizi etkilemez.

— Joe

Yanıtlar:

İyi tavsiye bir mantıkla gelir, böylece ne zaman kötü tavsiye haline geldiğini anlayabilirsiniz.

Köküne ait lost+foundolmanın amacı, kimin dosyası kaybolursa kaybedilsin, aniden herkese maruz kalmamasıdır. Ancak, bu durumda, tüm dosya sisteminde * pduck'e ait olmayan tek bir dosya olmamalıdır; bu nedenle lost+foundpduck'e sahip olmamanın bir dezavantajı yoktur .

* suroot atmak ve bir X uygulaması çalıştırmak gibi egzotik durumları engelleme . Ama eğer pduck kullanabilirse sudoya da subiz hiçbir şeyden bahsetmiyorsak, pduck sistem güvenliğini tamamen bozabilir.

— Joshua
kaynak

lost+found bir sistem dizinidir ve sistem dizinlerinin ve dosyalarının sahiplik ve izinlerine müdahale etmekten kaçınırım.

findKomut satırının izinlerini yükseltmedikçe şikayet eden başka dizinler (ve dosyalar) var, bu yüzden

sudo find ...

ve lost+foundolduğu gibi bırakın .

— sudodus
kaynak

Evet, bu yüzden ben düşündüm ama OTOH orada olmasıdır mklost+foundoluşturmak için komut ve onu yaratan benim mülkiyeti. Belki de $UID!=0;-) için kontrol etmez sadece korkunç bir komut .-) Ayrıca, sudokendi $ HOME kullanmak için zorla (az ya da çok) fikrini sevmiyorum .

— PerlDuck

lost+foundçok eski, sanırım UNIX'in ilk günlerinden beri ve bugünlerde ne zaman kullanıldığını gerçekten bilmiyorum. Ancak sistem dizinlerinin ve dosyalarının sahipliğini ve izinlerini tahrif etmekten kaçınmanın iyi bir genel politika olduğunu düşünüyorum (sahnenin arkasında ne olabileceğini gerçekten bilmiyorsanız).

— sudodus

Does not fscko dosyaları "kayıp" karşılaştığında orada dosyaları koydu? Fikir, fsckdosyaları koymak için zaten bir yere sahip olmasıdır (önce bir tane oluşturmak yerine). Not lost+foundsıradan boş dizine (4096 bayt) daha fazla alan (16384 bayt) kaplar.

— PerlDuck

Evet, en azından orijinal amaç ( chkdskMSDOS'ta kaybolan dosyalar ile aynı olana benzer ), ancak linux'da hiç veri görmediysem nadiren var. Günlük kaydı, dosyaları daha önceki yerlerine geri yükleyebilir, bu yüzden gitmelerine gerek yoktur lost+found. - Bu arada, bir lost+founddizin var /home, ama benim ev dizinde değil /home/sudodus, bu yüzden orada beni rahatsız etmez.

— sudodus

Katılıyorum. Ve de /homeben başka var l+fçünkü (ya beni rahatsız etmez) /homeve /home/pduckbenim makinede ayrı bölümler bulunmaktadır. İkincisi şifrelenir, ilki şifrelenmez. Ancak, beni çok fazla kızdırdığında, $ HOME'umu başka bir yere monte edebilir ve $ HOME'umdan tamamen kurtulmak için gerçek $ HOME'uma ( örneğin burada özetlediğim gibi) bağlayabilirim l+f. /// "Genişletilmiş tartışma… sohbete taşı" uyarısından kaçınmak için yorumlarımı birkaç dakika / saat içinde sileceğim .

— PerlDuck

Kaybolan + bulunan dizin hakkında gerçekten büyülü bir şey yok. Diğerleri gibi basit bir dizindir ve sadece bir sistem çökmesi veya dosya sistemi bozulmasından sonra bir fsck sırasında bulunan kayıp dosyaları / dizinleri tutmak için kullanılır.

Dosya sistemi oluşturulduğunda mkfs sırasında oluşturulur ve normalde boştur. Varsayılan izinlerin tek nedeni, hassas dosyaların bir fsck sırasında bulunması ve kurtarılması durumunda normal kullanıcıların görünür olmasını önlemektir. Modern çağda dosyaların kaybolduğunu ve bu klasöre konulduğunu görmek nadirdir.

Kaldırılırsa, oraya konması gereken herhangi bir dosya olması durumunda fsck'in gerektiği gibi yeniden oluşturacağına inanıyorum. Bu, bir kullanıcı için bir dosya sistemi olduğundan ve verileri meraklı gözlerden gizlemeye gerek kalmadan tek başına olduğu için, bulmanın şikayet etmesini veya değiştirmesini önlemek için izinlerin 755 olarak değiştirilememesinin hiçbir nedenini göremiyorum. mülkiyet. Bir kurtarma işlemi sırasında fsck'in izinlerini sıfırlaması mümkündür, ancak ciddi bir donanım arızası olmadığı sürece modern bir dosya sisteminde nadir bir olaydır.

Sadece kaldırmaya gelince, etraftaki tüm paranoyaların, verileri kurtarmak için fsck'in mümkün olduğunca az yapmasının en iyisi olduğuna inanıyorum, ancak pratikte gerçekten çok önemli olduğunu düşünmüyorum.

— penguin359
kaynak