[PATCH RESEND libgpiod v2 10/18] dbus: add the API definitions

[Bartosz Golaszewski]

On Tue, Jul 2, 2024 at 11:06 AM Thiago Macieira <thiago at kde.org> wrote:
>
> On Tuesday 2 July 2024 08:48:43 CEST Sverdlin, Alexander wrote:
> > > What's the point of this property? It looks racy, as the user (whichever
> > > it
> > > is) can stop using it soon after a true read, or the line can become used
> > > right after a false read? The latter could lead to TOCTOU problems.
> > >
> > > Wouldn't it be better to force users to RequestLine and get an error if
> > > the
> > > line is busy? Because if it wasn't busy, now the calling application knows
> > > nothing else can grab it.
> >
> > this approach would make the inspection itself racy, isn't it?
> > I'm thinking about two instances of "gpiocli info" running in parallel, they
> > would display GPIO lines randomly "busy" even in case none of them actually
> > is?
>
> Correct, but the race time would be very small. The status application need
> not keep the line requested for long, only enough to get the current state.
>
> In any case, my argument is for everything *except* for the status / info
> application. That's an outlier application, of which there's likely to be a
> single one in the system. However, there will likely be multiple applications
> that need lines for actual uses. The argument is that the presence of the
> property can lead application authors to check before RequestLine in order to
> present a message to their users, possibly because their code is simpler for
> reading a property than dealing with an error.
>
> Therefore, my advice is to not have the API that can lead to TOCTOU, even if
> by accident.

Unfortunately there's one issue with the above: requesting a line
(even as input) may result in the kernel driver triggering a physical
change in hardware which may be undesirable. Inspecting the "Used"
property only results in fetching a flag from the kernel and will
never make the driver act upon HW.

Bartosz