All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Avi Kivity <avi@redhat.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: pci device assignment as non-root?
Date: Thu, 15 Jan 2009 18:28:32 +0300	[thread overview]
Message-ID: <496F5620.4000105@msgid.tls.msk.ru> (raw)
In-Reply-To: <496F3CCD.3040603@redhat.com>

Avi Kivity wrote:
> Michael Tokarev wrote:
[]
>> After looking at the source I found this in
>> x86/kvm_main.c:assigned_device_update_intx():
>>
>>                 if (!capable(CAP_SYS_RAWIO))
>>                         return -EPERM;
[]
>> So it looks like some other trick is needed here (not cap_sys_rawio
>> but some traditional unix rwx thing), OR kvm binary has to be able
>> to drop privileges after all the init is done.
> 
> Dropping privileges is easy (well, need to account for all threads) but
> will not play well with hotplug.

It's either one or another for sure.  Personally I use kvm as a
sort of security tool, to run various untrusted stuff inside
guests.  For that, hotplug, while sometimes useful to have,
isn't at all required, and if there's a choice between hotplug
and stronger security I'll definitely prefer the latter.  And
sure thing having a choice is good in any case -- now there's
just no choice.

But maybe there's some other option to achieve similar effect,
i.e. to be able to open and initialize some (PCI/USB/network)
at startup without keeping root (or various CAP_*) all the
time?

>> The latter SEEMS to be easy as it only involves userspace (it's ok
>> for me to start the whole thing as root as long as it drops privs,
>> I don't need to give certain PCI devices to arbitrary users), but
>> has its own issues.  Namely, I'd like kvm to open disk image files
>> and stuff like that as non-root too, since it's the only way to
>> force read-only opens currently.
> 
> Looks like we need -drive ...,access=readonly

Yeah, that'd be good too.

Speaking of which, there's still a bug somewhere that causes a guest
to hang in case it tries to write to a virtual drive open in read-only
mode.  It *is* a bug, because it's pretty normal for various real drives
to be read-only (trivial example is write-protected floppy drive; many
scsi drives has read-only flag which can be turned on/off using hdparm
or sdparm), and with real drives on real hardware there's no hangs of
this sort, the system correctly recognizes read-only media without
hanging on an attempt to write.

Thanks!

/mjt

      reply	other threads:[~2009-01-15 15:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-15 11:21 pci device assignment as non-root? Michael Tokarev
2009-01-15 13:40 ` Avi Kivity
2009-01-15 15:28   ` Michael Tokarev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=496F5620.4000105@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.