From: Allen <email@example.com> To: Greg KH <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, Linux Kernel Mailing List <firstname.lastname@example.org>, Allen Pais <email@example.com>, Allen Pais <firstname.lastname@example.org> Subject: Re: [RFC] PCI: allow sysfs file owner to read the config space with CAP_SYS_RAWIO Date: Mon, 19 Oct 2020 18:30:16 +0530 [thread overview] Message-ID: <CAOMdWSJDJ-uXpis1WbG3LnOG7bMiif5Q4Maafv_a=55Y_qypfQ@mail.gmail.com> (raw) In-Reply-To: <20201016062027.GB569795@kroah.com> > > > > Access to pci config space is explictly checked with CAP_SYS_ADMIN > > in order to read configuration space past the frist 64B. > > > > Since the path is only for reading, could we use CAP_SYS_RAWIO? > > Why? What needs this reduced capability? Thanks for the review. We need read access to /sys/bus/pci/devices/, We need write access to config, remove, rescan & enable files under the device directory for each PCIe functions & the downstream PCIe port. We need r/w access to sysfs to unbind and rebind the root complex. > > > This patch contains a simpler fix, I would love to hear from the > > Maintainers on the approach. > > > > The other approach that I considered was to introduce and API > > which would check for multiple capabilities, something similar to > > perfmon_capable()/bpf_capable(). But I could not find more users > > for the API and hence dropped it. > > > > The problem I am trying to solve is to avoid handing out > > CAP_SYS_ADMIN for extended reads of the PCI config space. > > Who is reading this config space that doesn't have admin rights? And > what are they doing with it? > > One big problem is that some devices will crash if you do this wrong, > which is why we restricted it to root. Hopefully all of those devices > are now gone, but I don't think you can count on it. > > The "guaranteed safe" fields in the config space are already exported by > sysfs for all users to read, are they not sufficient? > > thanks, > > greg k-h -- - Allen
next prev parent reply other threads:[~2020-10-19 13:00 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-16 5:52 Allen Pais 2020-10-16 6:20 ` Greg KH 2020-10-19 13:00 ` Allen [this message] 2020-10-19 13:16 ` Greg KH 2020-10-19 13:21 ` Allen 2020-10-19 13:47 ` Greg KH 2020-10-19 14:32 ` Allen
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='CAOMdWSJDJ-uXpis1WbG3LnOG7bMiif5Q4Maafv_a=55Y_qypfQ@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC] PCI: allow sysfs file owner to read the config space with CAP_SYS_RAWIO' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).