[Gelistirici] libvirt paketinin kullanici/grup gereksinimleri - baselayout

Emre Erenoglu erenoglu at gmail.com
11 Haz 2010 Cum 14:35:03 EEST


2010/6/11 Ozan Çağlayan <ozan at pardus.org.tr>

> Emre Erenoglu wrote:
> > Merhaba,
> >
> > libvirt'in sunucu kismi olan libvirtd icin icin diger dagitimlar libvirtd
> > isimli bir grup kullaniyorlar Unix soketlerinin erisim haklari icin.
> > Virt-Manager vs. ile libvirt kullanacak kullanicilarin da libvirtd
> grubunda
> > olmasi gerekiyor.
> >
> > srwxrwx---  1 root libvirtd   0 2010-06-07 23:54 libvirt-sock
> > srwxrwxrwx  1 root libvirtd   0 2010-06-07 23:54 libvirt-sock-ro
> >
> > BIz de libvirtd grubunu ekleyelim mi yoksa mevcut "virt" grubunu mu
> > kullanalim?
>
> Artık diğer dagitimlar ne yapiyorsa onu yapalim grup konularında. Sonra
> temizlemek
> ve standardi takip etmek inanilmaz zor oluyor. Bu arada hatırlamıyorum ama
> belki 2009 veya
> corporate2 deposunda ilgili kullanıcı/grubu eklemiş olabilirim düşük
> ihtimal.
>

Ozan Hocam tekrar selamlar,

Simdi gene baktim, kendi pardus'umu XDMCP ile kullandigimdan yanilmisim.
Bizim libvirt ve virt-manager, gerekli polkit kutuphaneleri ile
derleniyorlar yani PolicyKit destegimiz var. Wheel grubu kullanicilar,
virt-manager'i calitirip dogrudan kullanici adi ve sifresi girerek sistemi
kullanabiliyorlar.

Yani libvirtd grubu yaratmamiza aslinda gerek yok, bizim libvirt soketleri
polkit destegi ile asagidaki gibi gorunuyor:

srwxrwxrwx  1 root root    0 2010-06-11 02:30 libvirt-sock
srwxrwxrwx  1 root root    0 2010-06-11 02:30 libvirt-sock-ro

Uzaktan baglanilmasi gerektiginde ise zaten virt-manager hard coded olarak
root kullanici olarak baglanmaya calisiyor, x11-ssh-askpass ile sifreyi alip
baglanti tamamlanabiliyor.

qemu kullanici ve grubunu ise yaratmak iyi olabilir.

Bununla ilgili olarak da capng ile derledigimizden, aslinda qemu prosesleri
calistirilirken root yetkileri birakiliyor. Ama gene de qemu olarak
calistirmak faydali olabilir.

Karari sana birakiyorum:

Linux process capabilities

The libvirt QEMU driver has a build time option allowing it to use the
libcap-ng <http://people.redhat.com/sgrubb/libcap-ng/index.html> library to
manage process capabilities. If this build option is enabled, then the QEMU
driver will use this to ensure that all process capabilities are dropped
before executing a QEMU virtual machine. Process capabilities are what gives
the 'root' account its high power, in particular the CAP_DAC_OVERRIDE
capability is what allows a process running as 'root' to access files owned
by any user.

If the QEMU driver is configured to run virtual machines as non-root, then
they will already loose all their process capabilities at time of startup.
The Linux capability feature is thus aimed primarily at the scenario where
the QEMU processes are running as root. In this case, before launching a
QEMU virtual machine, libvirtd will use libcap-ng APIs to drop all process
capabilities. It is important for administrators to note that this implies
the QEMU process will *only* be able to access files owned by root, and not
files owned by any other user.

Thus, if a vendor / distributor has configured their libvirt package to run
as 'qemu' by default, a number of changes will be required before an
administrator can change a host to run guests as root. In particular it will
be necessary to change ownership on the directories /var/run/libvirt/qemu/,
/var/lib/libvirt/qemu/ and /var/cache/libvirt/qemu/ back to root, in
addition to changing the /etc/libvirt/qemu.conf settings.
-- 
Emre
-------------- sonraki bölüm --------------
Bir HTML eklentisi temizlendi...
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20100611/693a1d59/attachment-0002.htm>


Gelistirici mesaj listesiyle ilgili daha fazla bilgi