Re: [PATCH bpf-next] tools: bpftool: allow unprivileged users to probe features

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/23/20 6:04 PM, Quentin Monnet wrote:
There is demand for a way to identify what BPF helper functions are
available to unprivileged users. To do so, allow unprivileged users to
run "bpftool feature probe" to list BPF-related features. This will only
show features accessible to those users, and may not reflect the full
list of features available (to administrators) on the system. For
non-JSON output, print an informational message stating so at the top of
the list.

Note that there is no particular reason why the probes were restricted
to root, other than the fact I did not need them for unprivileged and
did not bother with the additional checks at the time probes were added.

Cc: Richard Palethorpe <rpalethorpe@xxxxxxxx>
Cc: Michael Kerrisk <mtk.manpages@xxxxxxxxx>
Signed-off-by: Quentin Monnet <quentin@xxxxxxxxxxxxx>
---
  .../bpftool/Documentation/bpftool-feature.rst |  4 +++
  tools/bpf/bpftool/feature.c                   | 32 +++++++++++++------
  2 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/tools/bpf/bpftool/Documentation/bpftool-feature.rst b/tools/bpf/bpftool/Documentation/bpftool-feature.rst
index b04156cfd7a3..313888e87249 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-feature.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-feature.rst
@@ -49,6 +49,10 @@ DESCRIPTION
  		  Keyword **kernel** can be omitted. If no probe target is
  		  specified, probing the kernel is the default behaviour.
+ Running this command as an unprivileged user will dump only
+		  the features available to the user, which usually represent a
+		  small subset of the parameters supported by the system.
+

Looks good. I wonder whether the unprivileged should be gated behind an explicit
subcommand e.g. `--unprivileged`. My main worry is that if there's a misconfiguration
the emitted macro/ header file will suddenly contain a lot less defines and it might
go unnoticed if some optimizations in the BPF code are then compiled out by accident.
Maybe it would make sense to have a feature test for libcap and then also allow for
root to check on features for unpriv this way?

  	**bpftool feature probe dev** *NAME* [**full**] [**macros** [**prefix** *PREFIX*]]
  		  Probe network device for supported eBPF features and dump
  		  results to the console.
diff --git a/tools/bpf/bpftool/feature.c b/tools/bpf/bpftool/feature.c
index 88718ee6a438..f455bc5fcc64 100644
--- a/tools/bpf/bpftool/feature.c
+++ b/tools/bpf/bpftool/feature.c
@@ -471,6 +471,11 @@ probe_prog_type(enum bpf_prog_type prog_type, bool *supported_types,
  		}
res = bpf_probe_prog_type(prog_type, ifindex);
+	/* Probe may succeed even if program load fails, for unprivileged users
+	 * check that we did not fail because of insufficient permissions
+	 */
+	if (geteuid() && errno == EPERM)
+		res = false;
supported_types[prog_type] |= res;



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux