Linux'ta sembolik bir bağlantının sahibini neden değiştiresiniz?


12

Linux'ta sembolik bir bağlantının (sembolik bağ) sahibini veya grup sahibini değiştirmek mümkündür. Bir dosyanın neden bir dosyaya erişirken kullanılmadığından, neden birinin bunu yapmak isteyeceğini merak ediyordum.

Kullanışlı olabileceği tek bir kullanım durumunu hayal edebiliyorum: bir kullanıcının yapışkan bit içeren bir dizindeki bir sembolik bağlantısı silmesine izin vermek için

Bir sembolik bağlantının sahibinin veya grup sahibinin değiştirilmesinin yararlı olabileceği başka durumlar biliyor musunuz?

Yanıtlar:


6

Kökün Havva'nın yazabileceği bir dizinde çalıştığını varsayalım. fooBu dizinde Havva'ya ait olması gereken bir dosya var . Yani kök tipleri chown eve foo. Ama kök Enter'a basmadan hemen önce Eve koşar ln -sf /etc/passwd foo. Şimdi /etc/passwdHavva'ya ait! Kök, chown -h eve foosembolik bağlantıları izlememek için çalışabilirse, yapılabilecek en büyük zarar, aynı dizindeki başka bir dosyanın Havva'ya ait olarak değiştirilmesidir.

lchownbir dizin ağacının sahibini değiştirirken de kullanışlıdır. chownSembolik bir bağlantıyı aradığınız için , yanlışlıkla bir ağacın dışındaki bir dosyayı etkileme konusunda endişelenmenize gerek yoktur .


Msgstr "Kök, sembol bağlantılarını izlemediğinden emin olmak için chown -h bob foo'yu çalıştırabilirse, yapılabilecek en büyük zarar aynı dizindeki başka bir dosyanın Havva'ya ait olarak değiştirilmiş olmasıdır." Sanırım "chown -h eve foo" demek istiyorsun. Değiştirilebilecek diğer dosya, sembolik bağlantı değil mi?
user368507

@ user5528 Diğer dosya bir simge bağlantısı olmayabilir: Eve hala çalışabilir mv myfile foove root'un sahibi değişecektir myfile. Ancak myfileHavva'nın bu dizini oluşturabileceği veya bu dizine taşıyabileceği bir dosya olmalı, sistemdeki herhangi bir dosya olamaz.
Gilles 'SO

2
İlginç ve asker tarafından açıkça onaylanmış olsa da, bu cevabın soruyu nasıl ele aldığını göremiyorum. Daha çok chown -h, bir sembolik olması gerekmeyen, ancak yine de olabilecek bir dosyanın sahipliğini değiştirirken neden dikkatli bir önlem olarak kullanılabileceğini açıklamak daha iyidir. Bir kişinin aslında bir sembolik bağlantı olması amaçlanan bir dosyanın sahipliğini neden değiştirmek isteyebileceğini açıklamıyor.
Ivan X

chown"Ağacın dışındaki bir dosyanın" sahibini neden değiştirdiğiniz tek şey dizinin sahibidir?
Melab

@Melab Bir dizin ağacının sahibini değiştirdiğinizde , örneğin yardımcı programın bağlantısını kaldırdığınızda, her dizin girdisinde sistem çağrısını chown -Rçağıran (l)chown. Dizin girişi sembolik bir bağsa, o zaman chownsistem çağrısını çağırmamalısınız, çünkü bu, ağacın dışında bulunan bağlantının hedefini etkileyecektir.
Gilles 'SO- kötü olmayı bırak

8

Apache, yalnızca bağlantının sahibi hedefin sahibiyle eşleşiyorsa sembolik bağları izleyecek şekilde yapılandırılabilir. Bu, kullanıcıların sahip olmadıkları dosyalara (örneğin / etc / passwd) web erişimi için bağlantılar oluşturmasını önlemeye yardımcı olabilir.

... bu yüzden diyelim ki, kök olarak, apache'nin xymon veya başka bir şeye ait olan belirli bir günlük dosyasını görüntülemek için bir bağlantıyı takip etmesini istediniz , ancak sahibinin ne olduğuna bakılmaksızın apache'nin güvenliğini rahatlatmak istemediniz. . O zaman xymon'u sembolik bağlantının sahibi yapmak isteyebilirsiniz.


1
Tamam. İlgisiz olduğunu biliyorum ama apache'deki bu davranışın anlamı nedir? Yani kullanıcı dosyayı okuyabiliyorsa, neden web erişiminden okumak zahmete giriyor? thx
user368507

Sadece dosyayı okuyan yerel bir kullanıcı değil; apache okuyabilirse, potansiyel olarak herkes okuyabilir. Ve bazı apache güvenlik açığı bir symlink oluşturulmasına izin /etc/passwdverdiyse, badguy başka bir yerel erişime sahip olmadan bu dosyaya okuma erişimine sahip olabilir, ancak apache'ye ait olan symlink tarafından engellenir.
Lars Rohrbach

4

İlk cevap soruyu ele almıyor gibi görünüyor ve ikinci cevap sadece Apache için geçerli.

Genel olarak linux için düşünebileceğim bir şey, sıradan bir kullanıcının sadece sembolik bağın sahibi olması durumunda sembolik bir bağlantıya sabit bir bağlantı yapmasının mümkün olmasıdır. Neden böyle bir bağlantı kurmak istesin bilmiyorum.

Başka bir şey, sıradan bir kullanıcının bir dosyanın grup sahipliğini ancak kullanıcı dosyanın sahibi olması durumunda değiştirebilmesidir (ve aynı zamanda dosyanın eklendiği grubun bir üyesidir.) Bu, grubun sahipliğinin ne olduğu sorusunu getirir. sembolik bir bağlantı yapar. Bir kuruluşta, hangi takımın bağlantıya ihtiyaç duyacağını belirtmek bir etiket olarak yararlı olabilir.

Ayrıca, en azından Ubuntu'da, herkes sembolik bir bağlantının zaman damgasını güncelleyebilir. Ancak, yalnızca sahibinin izin vermesine izin veren bazı sistemler olabilir. Zaman damgasının sembolik bir bağlantı için ne kadar iyi olduğuna emin değilim, ancak ne kadar kullanıldığına dair bazı yararlı bilgiler verebilir.

Edit: Ben sadece sahiplik önemli olacağını başka bir neden fark ettim. Bağlantı, yalnızca bir dosyanın sahibinin dosyayı silebileceği veya yeniden adlandırabileceği yapışkan bir dizinin içinde olabilir.


0

Bir günlük dosyasına ekleyen bir program var. Bu günlük dosyaları her biri farklı bir adla aylık olarak oluşturulur. Yazılım tam dosya adını bulmak yerine, o ay için geçerli dosyayı işaret eden sembolik bir bağlantı olan "genel" bir dosya adı (veri.log diyelim) kullanıyorum. Bu bir cron işinde otomatikleştirilir.

Şimdi yeni bir aylık dosya oluşturuldukça, sembolik bağlantıyı yeni dosyaya yönlendirmelidir. Bir sahiplik / grup çakışması varsa, yazılım sembolik bağlantıyı değiştiremez. Bu nedenle, sembolik bağlantıyı değiştirmek için sahiplik / grup yazma ayrıcalıklarına ihtiyacınız var.


0

Açılış ekranınızdaki bir dosyaya bağlantı oluşturmak istiyorsanız, sembolik bağlantının

"/ Home / username / Masaüstü"

dizin.

Ve sembolik bağlantının kendisi root: root (0: 0) sahipliğine sahip olmalıdır, aksi takdirde bağlantı çalışmaz.

(Ubuntu / Debian vb.)

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.