Satu file ingin menjadi milik dua pengguna. Bagaimana? Tautan keras gagal


32

Dua program setuid, /usr/bin/bardan /usr/bin/baz, berbagi satu file konfigurasi foo. Mode file konfigurasi adalah 0640, karena menyimpan informasi sensitif. Program yang satu berjalan sebagai bar:bar(yaitu, sebagai bilah pengguna , bilah kelompok ); yang lain sebagai baz:baz. Mengubah pengguna bukanlah suatu pilihan, dan bahkan mengubah grup tidak akan lebih disukai.

Saya ingin menautkan file konfigurasi tunggal dengan /etc/bar/foodan /etc/baz/foo. Namun, ini gagal karena file harus, sejauh yang saya tahu, milik root:baratau milik root:baz.

Solusi potensial: Buat grup baru barbazdengan anggota bardan baz. Biarkan foomilik root:barbaz.

Itu terlihat seperti solusi yang cukup berat bagi saya. Apakah tidak ada cara yang lebih rapi dan mudah untuk berbagi file konfigurasi fooantara kedua program?

Untuk saat ini, saya mempertahankan dua, salinan file yang identik. Ini bekerja, tetapi jelas salah. Apa yang benar?

Sebagai informasi: Saya memiliki sedikit pengalaman dengan grup Unix dan tidak ada dengan setgid (2).


Pertanyaannya umumnya bertahap. Dalam kasus spesifik saya, kedua program tersebut adalah Exim4 dan Dovecot, program penanganan surat yang dapat membagikan kata sandi dan sertifikat TLS.
thb

8
solusi Ubuntu (& saya pikir Debian) untuk ini adalah ssl-certgrup, yang merupakan barbazgrup Anda . Standar ini adalah untuk mengatur semua kunci pribadi yang akan dimiliki oleh ssl-certgrup, dan menempatkan UID yang terkait dengan program yang perlu mengaksesnya ke dalam grup itu.
abligh

1
@abligh: Menarik. Sistem saya adalah Debian 8 jessie. Rupanya, ada paket ssl-certyang skrip postinst-nya, saat instalasi, membuat grup yang Anda gunakan. Saya tidak menyadarinya ssl-cert. Apache2 (diinstal pada host saya) merekomendasikan ssl-cert . Berbagai paket Exim dan Dovecot tidak, tetapi Postfix (tidak diinstal pada host saya) tergantung pada ssl-cert. Karena Apache, host saya memang memiliki grup ssl-cert , tetapi grup ini belum memiliki anggota. Terima kasih atas sarannya.
thb

5
Jadikan program setgid, bukan setuid. Program Setuid adalah ide yang buruk karena jika mereka dikompromikan, biner dapat diganti, menciptakan kuda trojan. (Pengecualian: root setuid, karena di sana Anda tidak punya pilihan.)
Gilles 'SO- stop being evil'

1
Apakah wiki.dovecot.org/HowTo/EximAndDovecotSASL mengatasi situasi spesifik Anda?
MvG

Jawaban:


50

Anda dapat menggunakan ACL sehingga file tersebut dapat dibaca oleh orang-orang di kedua grup.

chgrp bar file
chmod 640 file
setfacl -m g:baz:r-- file

Sekarang keduanya bardan bazgrup dapat membaca file.

Misalnya, inilah file yang dimiliki oleh bin: bin dengan mode 640.

$ ls -l foo
-rw-r-----+ 1 bin bin 5 Aug 17 12:19 foo

The +berarti ada sebuah set ACL, jadi mari kita lihat itu.

$ getfacl foo
# file: foo
# owner: bin
# group: bin
user::rw-
group::r--
group:sweh:r--
mask::r--
other::---

Kita dapat melihat baris group:sweh:r--: itu berarti orang-orang dalam grup swehdapat membacanya

Hei, itu aku!

$ id
uid=500(sweh) gid=500(sweh) groups=500(sweh)

Dan ya, saya bisa membaca file.

$ cat foo
data

23

Anda mungkin ingin mempertimbangkan kembali pernyataan-pernyataan ini:

Solusi potensial: Buat grup baraz baru yang anggotanya adalah bardan baz. Biarkan foomilik root:barbaz.

Itu terlihat seperti solusi yang cukup berat bagi saya. Apakah tidak ada cara yang lebih rapi dan mudah untuk berbagi file konfigurasi fooantara kedua program?

Mengapa terlalu berat untuk membuat grup baru? Melakukannya memiliki keuntungan sebagai berikut dibandingkan ACL:

  • Meskipun Anda telah mengutarakan ini sebagai hipotetis dengan perintah /usr/bin/bardan /usr/bin/baz, relevan bahwa kedua program ini dapat berbagi file konfigurasi. Ini menunjukkan bahwa program terkait secara alami. Membuat grup baru untuk mereka tampaknya menggambarkan hubungan yang benar-benar ada dan seharusnya memicu perilaku (seperti izin untuk membaca file konfigurasi umum).
  • Memecahkan masalah ini melalui grup adalah portabel untuk setiap Unix, artinya Anda dapat mengandalkan mekanisme yang sama, bekerja dengan cara yang persis sama, pada sistem apa pun yang mirip Unix atau Unix. ACL jauh lebih kompleks dan mudah dibawa dapat menjadi masalah.

Secara pribadi saya melihat ACL sebagai solusi yang berat di sini, dan dikelompokkan sebagai cara Unix tradisional yang lebih sederhana.


16

Saya akan berpikir ini akan menjadi penggunaan khas untuk Access Control Lists (ACL). Tambahkan kedua pengguna (atau grup) ke ACL file konfigurasi:

/etc/foo  root:root rw-------  # Traditional Unix ownership and permission for foo
$ setfacl -m user: bar: rw- / etc / foo # Mengizinkan bilah pengguna untuk membaca dan menulis foo
$ setfacl -m user: baz: rw- / etc / foo # Mengizinkan juga baz pengguna untuk membaca dan menulis foo

Anda mungkin harus menginstal paket acl terlebih dahulu.


3

Buat mode file 0660(atau bahkan 0440jika menulis tidak diperlukan) dan kepemilikan bar:baz. Kemudian satu proses dapat mengakses file berkat izin pengguna, yang lain berkat izin grup. Ini bekerja bahkan pada sistem file di mana ACL tidak.


2

Saya akan mengirimkan ini karena belum disebutkan. Meskipun ini mungkin bukan yang Anda inginkan, itu mungkin jawaban untuk orang lain dengan pertanyaan serupa.

Cara "baru" "cloud" adalah membuat semua konfigurasi ditangani oleh sistem manajemen konfigurasi (seperti koki , boneka , atau yang memungkinkan ). Maka tidak masalah bahwa Anda memiliki dua file yang berbeda tetapi identik di server, karena keduanya adalah salinan dari file tunggal dari sistem manajemen konfigurasi.

Keuntungan utama melakukannya seperti ini adalah bahwa konfigurasi Anda diversi (beserta semua konfigurasi lainnya), dan menggunakan server baru yang identik atau hampir sama menjadi sangat mudah sehingga ot dapat diotomatisasi.

(Sebagai catatan, karena Anda tidak menggunakan manajemen konfigurasi, saya akan menggunakan sistem grup seperti pada jawaban @ drg).

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.