Re: [PATCH] bpf.2: Change note on unprivileged access

Re: [PATCH] bpf.2: Change note on unprivileged access

[Michael Kerrisk (man-pages)]

Hello Richard,

On 7/29/19 2:58 PM, Richard Palethorpe wrote:
> This notes that the kernel now allows calls to bpf() without CAP_SYS_ADMIN
> under some circumstances.

Thanks. I have (at last) applied this patch.

In Linux 4.4, the allowed BPF helper functions that could
be called was, I think, governed by a check in sk_filter_func_proto().
Nowadays (Linux 5.6), it is, I think, governed by the check in
sk_filter_func_proto(). If that is the case, then probably there
are one or two more helper functions to be added to the list
(e.g., get_numa_node_id, map_push_elem, map_pop_elem).
Do you agree with my analysis?

Thanks,

Michael

> Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
> ---
>  man2/bpf.2 | 22 ++++++++++++++++++++--
>  1 file changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/man2/bpf.2 b/man2/bpf.2
> index b5c0869ae..a57ed9086 100644
> --- a/man2/bpf.2
> +++ b/man2/bpf.2
> @@ -1120,11 +1120,29 @@ The
>  .BR bpf ()
>  system call is Linux-specific.
>  .SH NOTES
> -In the current implementation, all
> +Prior to Linux 4.4, all
>  .BR bpf ()
>  commands require the caller to have the
>  .B CAP_SYS_ADMIN
> -capability.
> +capability. From 4.4 onwards an unprivileged user may create limited
> +programs of type
> +.BR BPF_PROG_TYPE_SOCKET_FILTER
> +and associated maps. However they may not store kernel pointers within
> +the maps and are presently limited to the following helper functions:
> +.IP * 3
> +get_random
> +.PD 0
> +.IP *
> +get_smp_processor_id
> +.IP *
> +tail_call
> +.IP *
> +ktime_get_ns
> +.PD 1
> +.PP
> +Unprivileged access may be blocked by setting the sysctl
> +.IR /proc/sys/kernel/unprivileged_bpf_disabled .
> +.\" commit 1be7f75d1668d6296b80bf35dcf6762393530afc
>  .PP
>  eBPF objects (maps and programs) can be shared between processes.
>  For example, after
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH] bpf.2: Change note on unprivileged access

[Richard Palethorpe]

Hello Michael,

Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> writes:

> Hello Richard,
>
> On 7/29/19 2:58 PM, Richard Palethorpe wrote:
>> This notes that the kernel now allows calls to bpf() without CAP_SYS_ADMIN
>> under some circumstances.
>
> Thanks. I have (at last) applied this patch.

:-)

>
> In Linux 4.4, the allowed BPF helper functions that could
> be called was, I think, governed by a check in sk_filter_func_proto().
> Nowadays (Linux 5.6), it is, I think, governed by the check in
> sk_filter_func_proto(). If that is the case, then probably there

It looks like bpf_base_func_proto() and sk_filter_func_proto(). Possibly
also cg_skb_func_proto() because it seems normal users can also attach a
cgroup skb filter program type (looking at bpf_prog_load() in syscall.c
for 5.7).

> are one or two more helper functions to be added to the list
> (e.g., get_numa_node_id, map_push_elem, map_pop_elem).
> Do you agree with my analysis?

Yes, at least those. IMO this is such a fast moving target it might be
best to direct users towards <linux/bpf.h>.

>
> Thanks,
>
> Michael
>
>> Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
>> ---
>>  man2/bpf.2 | 22 ++++++++++++++++++++--
>>  1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/man2/bpf.2 b/man2/bpf.2
>> index b5c0869ae..a57ed9086 100644
>> --- a/man2/bpf.2
>> +++ b/man2/bpf.2
>> @@ -1120,11 +1120,29 @@ The
>>  .BR bpf ()
>>  system call is Linux-specific.
>>  .SH NOTES
>> -In the current implementation, all
>> +Prior to Linux 4.4, all
>>  .BR bpf ()
>>  commands require the caller to have the
>>  .B CAP_SYS_ADMIN
>> -capability.
>> +capability. From 4.4 onwards an unprivileged user may create limited
>> +programs of type
>> +.BR BPF_PROG_TYPE_SOCKET_FILTER
>> +and associated maps. However they may not store kernel pointers within
>> +the maps and are presently limited to the following helper functions:
>> +.IP * 3
>> +get_random
>> +.PD 0
>> +.IP *
>> +get_smp_processor_id
>> +.IP *
>> +tail_call
>> +.IP *
>> +ktime_get_ns
>> +.PD 1
>> +.PP
>> +Unprivileged access may be blocked by setting the sysctl
>> +.IR /proc/sys/kernel/unprivileged_bpf_disabled .
>> +.\" commit 1be7f75d1668d6296b80bf35dcf6762393530afc
>>  .PP
>>  eBPF objects (maps and programs) can be shared between processes.
>>  For example, after
>>


--
Thank you,
Richard.

Re: [PATCH] bpf.2: Change note on unprivileged access

[Michael Kerrisk (man-pages)]

[CC += Quentin]

Hello Richard (and Quentin, Daniel, Alexei),

On Fri, 17 Apr 2020 at 15:28, Richard Palethorpe <rpalethorpe@suse.de> wrote:
>
> Hello Michael,
>
> Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> writes:
>
> > Hello Richard,
> >
> > On 7/29/19 2:58 PM, Richard Palethorpe wrote:
> >> This notes that the kernel now allows calls to bpf() without CAP_SYS_ADMIN
> >> under some circumstances.
> >
> > Thanks. I have (at last) applied this patch.
>
> :-)
>
> >
> > In Linux 4.4, the allowed BPF helper functions that could
> > be called was, I think, governed by a check in sk_filter_func_proto().
> > Nowadays (Linux 5.6), it is, I think, governed by the check in
> > sk_filter_func_proto(). If that is the case, then probably there
>
> It looks like bpf_base_func_proto() and sk_filter_func_proto(). Possibly
> also cg_skb_func_proto() because it seems normal users can also attach a
> cgroup skb filter program type (looking at bpf_prog_load() in syscall.c
> for 5.7).

Thanks for the pointer to bpf_prog_load(). But, I must admit I'm
having trouble to follow the code. Can you say some more about how you
deduce the involvement of sk_filter_func_proto() and
cg_skb_func_proto()?

> > are one or two more helper functions to be added to the list
> > (e.g., get_numa_node_id, map_push_elem, map_pop_elem).
> > Do you agree with my analysis?
>
> Yes, at least those. IMO this is such a fast moving target it might be
> best to direct users towards <linux/bpf.h>.

Are you aware of bpf-helpers(7) [1], which is generated [2] from that
file? It seems like this would be the place to document which helpers
can be used by unprivileged processes.

Quentin, Daniel, Alexei, do you have any thoughts here?

Thanks,

Michael

[1] http://man7.org/linux/man-pages/man7/bpf-helpers.7.html
[2] https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=53666f6c30451cde022f65d35a8d448f5a7132ba


--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH] bpf.2: Change note on unprivileged access

[Michael Kerrisk (man-pages)]

[Adding in correct address for Quentin, since his address has changed]

On Sat, 18 Apr 2020 at 09:34, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
>
> [CC += Quentin]
>
> Hello Richard (and Quentin, Daniel, Alexei),
>
> On Fri, 17 Apr 2020 at 15:28, Richard Palethorpe <rpalethorpe@suse.de> wrote:
> >
> > Hello Michael,
> >
> > Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> writes:
> >
> > > Hello Richard,
> > >
> > > On 7/29/19 2:58 PM, Richard Palethorpe wrote:
> > >> This notes that the kernel now allows calls to bpf() without CAP_SYS_ADMIN
> > >> under some circumstances.
> > >
> > > Thanks. I have (at last) applied this patch.
> >
> > :-)
> >
> > >
> > > In Linux 4.4, the allowed BPF helper functions that could
> > > be called was, I think, governed by a check in sk_filter_func_proto().
> > > Nowadays (Linux 5.6), it is, I think, governed by the check in
> > > sk_filter_func_proto(). If that is the case, then probably there
> >
> > It looks like bpf_base_func_proto() and sk_filter_func_proto(). Possibly
> > also cg_skb_func_proto() because it seems normal users can also attach a
> > cgroup skb filter program type (looking at bpf_prog_load() in syscall.c
> > for 5.7).
>
> Thanks for the pointer to bpf_prog_load(). But, I must admit I'm
> having trouble to follow the code. Can you say some more about how you
> deduce the involvement of sk_filter_func_proto() and
> cg_skb_func_proto()?
>
> > > are one or two more helper functions to be added to the list
> > > (e.g., get_numa_node_id, map_push_elem, map_pop_elem).
> > > Do you agree with my analysis?
> >
> > Yes, at least those. IMO this is such a fast moving target it might be
> > best to direct users towards <linux/bpf.h>.
>
> Are you aware of bpf-helpers(7) [1], which is generated [2] from that
> file? It seems like this would be the place to document which helpers
> can be used by unprivileged processes.
>
> Quentin, Daniel, Alexei, do you have any thoughts here?
>
> Thanks,
>
> Michael
>
> [1] http://man7.org/linux/man-pages/man7/bpf-helpers.7.html
> [2] https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=53666f6c30451cde022f65d35a8d448f5a7132ba
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH] bpf.2: Change note on unprivileged access

[Quentin Monnet]

Hi Michael, Richard,

Thank you Michael for the Cc :). Answers inline.

2020-04-18 09:36 UTC+0200 ~ Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com>
> [Adding in correct address for Quentin, since his address has changed]
> 
> On Sat, 18 Apr 2020 at 09:34, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>>
>> [CC += Quentin]
>>
>> Hello Richard (and Quentin, Daniel, Alexei),
>>
>> On Fri, 17 Apr 2020 at 15:28, Richard Palethorpe <rpalethorpe@suse.de> wrote:
>>>
>>> Hello Michael,
>>>
>>> Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> writes:
>>>
>>>> Hello Richard,
>>>>
>>>> On 7/29/19 2:58 PM, Richard Palethorpe wrote:
>>>>> This notes that the kernel now allows calls to bpf() without CAP_SYS_ADMIN
>>>>> under some circumstances.
>>>>
>>>> Thanks. I have (at last) applied this patch.
>>>
>>> :-)
>>>
>>>>
>>>> In Linux 4.4, the allowed BPF helper functions that could
>>>> be called was, I think, governed by a check in sk_filter_func_proto().
>>>> Nowadays (Linux 5.6), it is, I think, governed by the check in
>>>> sk_filter_func_proto(). If that is the case, then probably there
>>>
>>> It looks like bpf_base_func_proto() and sk_filter_func_proto(). Possibly
>>> also cg_skb_func_proto() because it seems normal users can also attach a
>>> cgroup skb filter program type (looking at bpf_prog_load() in syscall.c
>>> for 5.7).
>>
>> Thanks for the pointer to bpf_prog_load(). But, I must admit I'm
>> having trouble to follow the code. Can you say some more about how you
>> deduce the involvement of sk_filter_func_proto() and
>> cg_skb_func_proto()?

sk_filter_func_proto() and cg_skb_func_proto() are used by the verifier
(as env->ops->get_func_proto) to check that the helper functions used
with the given program types (BPF_PROG_TYPE_SOCKET_FILTER and
BPF_PROG_TYPE_CGROUP_SKB, respectively) are acceptable.

Those functions are associated to the relevant types by macro
BPF_PROG_TYPE() defined in include/linux/bpf.h and called in
include/linux/bpf_types.h.

The aforementioned program types are indeed the two that may be
available to unprivileged users, as can be seen in bpf_prog_load() [0].

[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/syscall.c?h=v5.6#n2039

>>
>>>> are one or two more helper functions to be added to the list
>>>> (e.g., get_numa_node_id, map_push_elem, map_pop_elem).
>>>> Do you agree with my analysis?
>>>
>>> Yes, at least those. IMO this is such a fast moving target it might be
>>> best to direct users towards <linux/bpf.h>.
>>
>> Are you aware of bpf-helpers(7) [1], which is generated [2] from that
>> file? It seems like this would be the place to document which helpers
>> can be used by unprivileged processes.
>>
>> Quentin, Daniel, Alexei, do you have any thoughts here?

Right, it's moving fast and it is a bit tricky to keep lists like this
up-to-date. My first proposal for bpf-helpers(7) would include the list
of program types compatible with each helper, but we decided that it
would be too hard to maintain and I removed it (bcc tries to keep a
list, though [1], but does not mention unprivileged usage). We do
require contributors creating new helpers to document their function
(the documentation is even parsed for producing a header for libbpf, so
it's a strict requirement) but having people scan all the documentation
to find the lists they should update is another story.

I feel the same here: the list of helpers available to unprivileged has
grown quite a bit since 4.4, and we will struggle to present updated
information to readers. Especially when we see how outdated bpf(2) is at
the moment. My suggestion would be to stick to a generic comment,
something like “However [unprivileged users] may not store kernel
pointers within the maps and are presently only a subset of the helper
functions compatible with those program types”.

Then the bpf-helpers(7) has the following note: “net/core/filter.c
contains the definition of most network-related helper functions, and
the list of program types from which they can be used.” It is not ideal,
but at least it indicates how to get accurate information. We could
maybe add another note in that page saying that unprivileged users get
access to functions listed in sk_filter_func_proto() and
cg_skb_func_proto(), plus bpf_base_func_proto() before the check on
CAP_SYS_ADMIN.

Let me know if you wanted me to send a patch with such a note, I plan to
submit fixes for helpers doc this week anyway.

Thanks,
Quentin


[1] https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md

Re: [PATCH] bpf.2: Change note on unprivileged access

[Michael Kerrisk (man-pages)]

Hello Quentin

Thank you for replying!

On 4/20/20 11:08 AM, Quentin Monnet wrote:
> Hi Michael, Richard,
> 
> Thank you Michael for the Cc :). Answers inline.
> 
> 2020-04-18 09:36 UTC+0200 ~ Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com>
>> [Adding in correct address for Quentin, since his address has changed]
>>
>> On Sat, 18 Apr 2020 at 09:34, Michael Kerrisk (man-pages)
>> <mtk.manpages@gmail.com> wrote:
>>>
>>> [CC += Quentin]
>>>
>>> Hello Richard (and Quentin, Daniel, Alexei),
>>>
>>> On Fri, 17 Apr 2020 at 15:28, Richard Palethorpe <rpalethorpe@suse.de> wrote:
>>>>
>>>> Hello Michael,
>>>>
>>>> Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> writes:
>>>>
>>>>> Hello Richard,
>>>>>
>>>>> On 7/29/19 2:58 PM, Richard Palethorpe wrote:
>>>>>> This notes that the kernel now allows calls to bpf() without CAP_SYS_ADMIN
>>>>>> under some circumstances.
>>>>>
>>>>> Thanks. I have (at last) applied this patch.
>>>>
>>>> :-)
>>>>
>>>>>
>>>>> In Linux 4.4, the allowed BPF helper functions that could
>>>>> be called was, I think, governed by a check in sk_filter_func_proto().
>>>>> Nowadays (Linux 5.6), it is, I think, governed by the check in
>>>>> sk_filter_func_proto(). If that is the case, then probably there
>>>>
>>>> It looks like bpf_base_func_proto() and sk_filter_func_proto(). Possibly
>>>> also cg_skb_func_proto() because it seems normal users can also attach a
>>>> cgroup skb filter program type (looking at bpf_prog_load() in syscall.c
>>>> for 5.7).
>>>
>>> Thanks for the pointer to bpf_prog_load(). But, I must admit I'm
>>> having trouble to follow the code. Can you say some more about how you
>>> deduce the involvement of sk_filter_func_proto() and
>>> cg_skb_func_proto()?
> 
> sk_filter_func_proto() and cg_skb_func_proto() are used by the verifier
> (as env->ops->get_func_proto) to check that the helper functions used
> with the given program types (BPF_PROG_TYPE_SOCKET_FILTER and
> BPF_PROG_TYPE_CGROUP_SKB, respectively) are acceptable.
> 
> Those functions are associated to the relevant types by macro
> BPF_PROG_TYPE() defined in include/linux/bpf.h and called in
> include/linux/bpf_types.h.
> 
> The aforementioned program types are indeed the two that may be
> available to unprivileged users, as can be seen in bpf_prog_load() [0].
> 
> [0]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/syscall.c?h=v5.6#n2039
> 
>>>
>>>>> are one or two more helper functions to be added to the list
>>>>> (e.g., get_numa_node_id, map_push_elem, map_pop_elem).
>>>>> Do you agree with my analysis?
>>>>
>>>> Yes, at least those. IMO this is such a fast moving target it might be
>>>> best to direct users towards <linux/bpf.h>.
>>>
>>> Are you aware of bpf-helpers(7) [1], which is generated [2] from that
>>> file? It seems like this would be the place to document which helpers
>>> can be used by unprivileged processes.
>>>
>>> Quentin, Daniel, Alexei, do you have any thoughts here?
> 
> Right, it's moving fast and it is a bit tricky to keep lists like this
> up-to-date. My first proposal for bpf-helpers(7) would include the list
> of program types compatible with each helper, but we decided that it
> would be too hard to maintain and I removed it (bcc tries to keep a
> list, though [1], but does not mention unprivileged usage). We do
> require contributors creating new helpers to document their function
> (the documentation is even parsed for producing a header for libbpf, so
> it's a strict requirement) but having people scan all the documentation
> to find the lists they should update is another story.
> 
> I feel the same here: the list of helpers available to unprivileged has
> grown quite a bit since 4.4, and we will struggle to present updated
> information to readers. Especially when we see how outdated bpf(2) is at
> the moment. My suggestion would be to stick to a generic comment,
> something like “However [unprivileged users] may not store kernel
> pointers within the maps and are presently only a subset of the helper
> functions compatible with those program types”.
> 
> Then the bpf-helpers(7) has the following note: “net/core/filter.c
> contains the definition of most network-related helper functions, and
> the list of program types from which they can be used.” It is not ideal,
> but at least it indicates how to get accurate information. We could
> maybe add another note in that page saying that unprivileged users get
> access to functions listed in sk_filter_func_proto() and
> cg_skb_func_proto(), plus bpf_base_func_proto() before the check on
> CAP_SYS_ADMIN.

So, just to confirm my understanding, the current set of helpers
permitted to unprivileged callers is:

    From sk_filter_func_proto():
        bpf_skb_load_bytes_proto
        bpf_skb_load_bytes_relative_proto
        bpf_get_socket_cookie_proto
        bpf_get_socket_uid_proto
        bpf_skb_event_output_proto
    From cg_skb_func_proto():
        bpf_get_local_storage_proto
        bpf_sk_fullsock_proto
        bpf_sk_storage_get_proto
        bpf_sk_storage_delete_proto
        bpf_skb_event_output_proto
        bpf_skb_cgroup_id_proto
        bpf_tcp_sock_proto
        bpf_get_listener_sock_proto
        bpf_skb_ecn_set_ce_proto
    From bpf_base_func_proto():
        bpf_map_lookup_elem_proto
        bpf_map_update_elem_proto
        bpf_map_delete_elem_proto
        bpf_map_push_elem_proto
        bpf_map_pop_elem_proto
        bpf_map_peek_elem_proto
        bpf_get_prandom_u32_proto
        bpf_get_raw_smp_processor_id_proto
        bpf_get_numa_node_id_proto
        bpf_tail_call_proto
        bpf_ktime_get_ns_proto

I think that man-pages patches along the lines you mention
would be a good start (although the references to kernel sources
may be a bit fragile), so if you would be willing to write those,
it would be great.

Just by the way, is it not possible to add notes to the text
of each helper to say that it is usable by an unprivileged caller?
I know this is also fragile, in the case of subsequent additions
and changes, but it would make the user-space programmer's life
a little easier (since they would not always be forced to look
at the kernel source).

> Let me know if you wanted me to send a patch with such a note, I plan to
> submit fixes for helpers doc this week anyway.

Yes please!

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH] bpf.2: Change note on unprivileged access

[Quentin Monnet]

2020-04-22 14:26 UTC+0200 ~ Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com>

[...]

> So, just to confirm my understanding, the current set of helpers
> permitted to unprivileged callers is:
> 
>     From sk_filter_func_proto():
>         bpf_skb_load_bytes_proto
>         bpf_skb_load_bytes_relative_proto
>         bpf_get_socket_cookie_proto
>         bpf_get_socket_uid_proto
>         bpf_skb_event_output_proto
>     From cg_skb_func_proto():
>         bpf_get_local_storage_proto
>         bpf_sk_fullsock_proto
>         bpf_sk_storage_get_proto
>         bpf_sk_storage_delete_proto
>         bpf_skb_event_output_proto
>         bpf_skb_cgroup_id_proto
>         bpf_tcp_sock_proto
>         bpf_get_listener_sock_proto
>         bpf_skb_ecn_set_ce_proto
>     From bpf_base_func_proto():
>         bpf_map_lookup_elem_proto
>         bpf_map_update_elem_proto
>         bpf_map_delete_elem_proto
>         bpf_map_push_elem_proto
>         bpf_map_pop_elem_proto
>         bpf_map_peek_elem_proto
>         bpf_get_prandom_u32_proto
>         bpf_get_raw_smp_processor_id_proto
>         bpf_get_numa_node_id_proto
>         bpf_tail_call_proto
>         bpf_ktime_get_ns_proto

Hi Michael,
Yes, this looks accurate at this time.

> I think that man-pages patches along the lines you mention
> would be a good start (although the references to kernel sources
> may be a bit fragile), so if you would be willing to write those,
> it would be great.
> 
> Just by the way, is it not possible to add notes to the text
> of each helper to say that it is usable by an unprivileged caller?
> I know this is also fragile, in the case of subsequent additions
> and changes, but it would make the user-space programmer's life
> a little easier (since they would not always be forced to look
> at the kernel source).

It would be possible of course, but I am convinced it would add to the
maintenance load and grow quickly out of sync. New helpers will be
added, some existing ones could be opened to unprivileged, and so on. I
would prefer to avoid that.

I agree that the note about kernel structs to check is fragile too, on a
second thought I will not send it for now.

What we could do instead is rely on bpftool. It is a utility for
introspection, management etc. of BPF objects (see
tools/bpf/bpftool/Documentation in kernel repo for more info). It is
able to probe and dump the list of supported BPF prog/map types and BPF
helper functions on the system, with "bpftool feature probe". This
feature probing is currently reserved for root, but simply because it
was easier to implement that way, and could probably be extended to
unprivileged.

So I would suggest we work to have bpftool dump the list of helpers for
non-root - I can add that to my to-do list -, and then add a note to the
manual page to mention it. Actually I can add the note already, since
admins may be interested in probing a given helper for availability.

What do you think?
Quentin