From: Greg KH <greg@kroah.com>
To: Chris Wright <chrisw@sous-sol.org>
Cc: jbarnes@virtuousgeek.org, matthew@wil.cx,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, ddutile@redhat.com,
alex.williamson@redhat.com
Subject: Re: [RFC PATCH] sysfs: bin_attr permission checking
Date: Wed, 12 May 2010 12:13:36 -0700 [thread overview]
Message-ID: <20100512191336.GA30678@kroah.com> (raw)
In-Reply-To: <20100512184713.GV28034@sequoia.sous-sol.org>
On Wed, May 12, 2010 at 11:47:13AM -0700, Chris Wright wrote:
> The PCI config space bin_attr read handler has a hardcoded CAP_SYS_ADMIN
> check to verify privileges before allowing a user to read device
> dependent config space. This is meant to protect from an unprivileged
> user potentially locking up the box.
>
> When assigning a PCI device directly to a guest with libvirt and KVM, the
> sysfs config space file is chown'd to the user that the KVM guest will
> run as. The guest needs to have full access to the device's config
> space since it's responsible for driving the device. However, despite
> being the owner of the sysfs file, the CAP_SYS_ADMIN check will not
> allow read access beyond the config header.
>
> This patch adds a new bin_attr->read_file() callback which adds a struct
> file to the normal argument list. This allows an implementation such as
> PCI config space bin_attr read_file handler to check both inode
> permission as well as privileges to determine whether to allow
> privileged actions through the handler.
Ick, this is all because we like showing different information if the
user is "privileged or not" :(
Turns out, that this probably isn't the best user api to implement,
remind me never to do that again...
> This is just RFC, although I've tested that it does allow the chown +
> read to work as expected. Any other ideas of how to handle this are
> welcome.
Can we just pass in the 'file' for all users of the bin files instead of
the dentry? You can always get the dentry from the file (as your patch
showes), and there isn't that many users of this interface. I'd really
rather not have two different types of callbacks here.
thanks,
greg k-h
next prev parent reply other threads:[~2010-05-12 19:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-12 18:47 [RFC PATCH] sysfs: bin_attr permission checking Chris Wright
2010-05-12 19:13 ` Greg KH [this message]
2010-05-12 19:28 ` Chris Wright
2010-05-12 19:39 ` Greg KH
2010-05-12 19:44 ` Chris Wright
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=20100512191336.GA30678@kroah.com \
--to=greg@kroah.com \
--cc=alex.williamson@redhat.com \
--cc=chrisw@sous-sol.org \
--cc=ddutile@redhat.com \
--cc=jbarnes@virtuousgeek.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew@wil.cx \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox