Mengapa mengubah pemilik tautan simbolis di linux?


12

Di linux dimungkinkan untuk mengubah pemilik atau pemilik grup dari tautan simbolik (symlink). Saya bertanya-tanya mengapa seseorang ingin melakukan itu, karena izin symlink tidak digunakan ketika mengakses file melalui itu.

Saya hanya bisa membayangkan satu use case di mana itu bisa berguna: untuk memungkinkan pengguna untuk menghapus symlink di direktori dengan bit yang lengket.

Apakah Anda tahu kasus lain di mana mungkin berguna untuk mengubah pemilik atau pemilik grup dari symlink?

Jawaban:


6

Misalkan root bekerja di direktori yang dapat ditulis oleh Hawa. Ada file foodi direktori ini yang perlu diubah untuk menjadi milik Hawa. Jadi jenis root chown eve foo. Tapi sebelum akar hit Enter, Eve berjalan ln -sf /etc/passwd foo. Sekarang /etc/passwdmilik Hawa! Jika root dapat berjalan chown -h eve foountuk memastikan tidak mengikuti symlink, maka kerugian terbesar yang dapat dilakukan adalah bahwa beberapa file lain dalam direktori yang sama telah diubah menjadi milik Eve.

lchownjuga nyaman ketika Anda mengubah pemilik pohon direktori. Anda tidak perlu khawatir tentang secara tidak sengaja mempengaruhi file di luar pohon karena Anda memanggil chowntautan simbolis.


"Jika root dapat menjalankan chown-h bob foo untuk memastikan tidak mengikuti symlink, maka kerugian terbesar yang dapat dilakukan adalah bahwa beberapa file lain dalam direktori yang sama telah diubah menjadi milik Eve." Saya kira maksud Anda "chown-h eve foo". File lain yang mungkin diubah, itu adalah tautan simbolik apakah saya benar?
user368507

@ user5528 File lain mungkin bukan symlink: Eve masih bisa berjalan mv myfile foo, dan root akan akhirnya mengubah pemilik myfile. Tetapi myfileharus menjadi file yang Hawa bisa buat atau pindahkan ke direktori itu, itu tidak bisa berupa file apa pun di sistem.
Gilles 'SO- berhenti bersikap jahat'

2
Meski menarik, dan jelas disetujui oleh penanya, saya tidak melihat bagaimana jawaban ini menjawab pertanyaan. Tampaknya lebih menjelaskan mengapa orang dapat menggunakan chown -hsebagai ukuran peringatan ketika mengubah kepemilikan file yang tidak seharusnya menjadi symlink, tetapi masih mungkin (kasus tepi, IMO). Itu tidak menjelaskan mengapa orang mungkin ingin mengubah kepemilikan file yang sebenarnya dimaksudkan sebagai symlink, yang merupakan pertanyaan yang diajukan.
Ivan X

Mengapa chownmengubah pemilik "file di luar pohon" adalah semua yang Anda ubah adalah pemilik direktori?
Melab

@Elab Ketika Anda mengubah pemilik pohon direktori , yaitu unning utilitas chown -R, yang memanggil (l)chownsistem panggilan pada setiap entri direktori. Jika entri direktori adalah tautan simbolis maka Anda tidak boleh memanggil chownsistem panggilan karena itu akan mempengaruhi target tautan yang mungkin berada di luar pohon.
Gilles 'SANGAT berhenti menjadi jahat'

8

Apache dapat dikonfigurasi untuk mengikuti symlinks hanya jika pemilik tautan cocok dengan pemilik tujuan. Ini dapat membantu mencegah pengguna membuat tautan untuk akses web ke file yang bukan miliknya (mis. / Etc / passwd).

... jadi katakanlah Anda, sebagai root, ingin apache mengikuti tautan untuk menampilkan logfile tertentu, yang dimiliki oleh xymon atau sesuatu, tetapi Anda tidak ingin melonggarkan keamanan apache dengan mengizinkannya mengikuti symlink terlepas dari pemiliknya . Maka Anda mungkin ingin menjadikan xymon sebagai pemilik symlink.


1
Baik. Saya tahu ini tidak terkait tetapi apa gunanya perilaku ini di apache? Maksud saya jika pengguna dapat membaca file, mengapa repot-repot membacanya dari akses web? thx
user368507

Ya, itu bukan hanya pengguna lokal yang membaca file; jika apache bisa membacanya, maka berpotensi semua orang bisa membacanya. Dan jika beberapa kerentanan apache memungkinkan pembuatan symlink /etc/passwd, maka badguy mungkin telah membaca akses ke file itu tanpa memiliki akses lokal lainnya - tetapi akan digagalkan oleh symlink yang dimiliki oleh apache.
Lars Rohrbach

4

Jawaban pertama tampaknya tidak mendukung pertanyaan, dan yang kedua hanya berlaku untuk Apache.

Satu hal yang dapat saya pikirkan untuk linux secara umum adalah bahwa hanya mungkin bagi pengguna biasa untuk membuat tautan keras ke tautan simbolik jika pengguna adalah pemilik tautan simbolik. Mengapa orang ingin membuat tautan seperti itu, saya tidak tahu.

Hal lain adalah bahwa pengguna biasa hanya dapat mengubah kepemilikan grup file jika pengguna memiliki file (dan juga anggota grup file yang ditambahkan.) Itu memunculkan pertanyaan tentang apa kepemilikan grup dari file tautan simbolik tidak. Dalam suatu organisasi, mungkin berguna sebagai tanda untuk menunjukkan tim mana yang membutuhkan tautan.

Juga, setidaknya di Ubuntu, siapa pun dapat memperbarui stempel waktu tautan simbolik. Namun, mungkin ada beberapa sistem yang hanya mengizinkan pemiliknya. Apa gunanya cap waktu untuk tautan simbolis, saya tidak yakin, tetapi mungkin memberikan beberapa informasi yang berguna tentang berapa banyak yang digunakan.

Sunting: Saya baru menyadari alasan lain mengapa kepemilikan menjadi penting. Tautan itu bisa berada di dalam direktori tempel, di mana hanya pemilik file yang dapat menghapus atau mengganti namanya.


0

Saya memiliki program yang ditambahkan ke file log. File log ini dibuat setiap bulan dengan nama yang berbeda. Daripada memiliki perangkat lunak mencari tahu nama file yang tepat, saya menggunakan nama file "generik" (katakan data.log) yang merupakan tautan simbolis yang menunjuk ke file saat ini untuk bulan itu. Ini otomatis pada pekerjaan cron.

Sekarang saat file bulanan baru dibuat, ia perlu mengarahkan tautan simbolik ke file baru. Jika ada konflik kepemilikan / grup, perangkat lunak tidak dapat mengubah tautan simbolik. Jadi, Anda memerlukan hak istimewa kepemilikan / grup untuk mengubah tautan simbolik.


0

Jika Anda ingin memiliki tautan ke file di layar pembuka, tautan simbolis harus berada di

"/ home / nama pengguna / Desktop"

direktori.

Dan, tautan simbolik itu sendiri harus memiliki kepemilikan root: root (0: 0), jika tidak tautan tersebut tidak akan berfungsi.

(Ubuntu / Debian dll.)

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.