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

On Tue, Jul 2, 2024 at 11:06=E2=80=AFAM Thiago Macieira <[email protected]> wr=
ote:
>
> 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 (whiche=
ver
> > > 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 actu=
ally
> > is?
>
> Correct, but the race time would be very small. The status application ne=
ed
> not keep the line requested for long, only enough to get the current stat=
e.
>
> 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 applicat=
ions
> that need lines for actual uses. The argument is that the presence of the
> property can lead application authors to check before RequestLine in orde=
r 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