[GRASS-dev] Question regarding GRASS_NOTIFY

[Nicklas Larsson]

> On 3 Mar 2022, at 22:20, Glynn Clements <glynn at gclements.plus.com> wrote:
> 
> 
> Nicklas Larsson via grass-dev wrote:
> 
>> Is there anyone out there who know about usage of the environment
>> variable GRASS_NOTIFY, historically and in the present?
> 
> It's an external interface; it isn't used internally.
> 
> The intention is described in the email you cited: to allow a program
> (specifically, ximgview or similar) to be notified of any changes to
> the image file generated by the display library. It isn't required by
> the GUI because the GUI can assume that the image will only be
> modified by d.* commands which the GUI itself runs, so it can refresh
> the view upon their completion.
> 
> The idea was to support the use of d.* commands from a shell,
> providing something similar to the "monitor" system that was being
> replaced at the time. I've have no idea whether such usage is still
> common or even officially supported (but scripts/wxpyimgview is still
> there).
> 

I personally never had the need for the use of GRASS in this way, so forgive
my ignorance in this regard.
However, one thing stands out very clear from my newly gained experience:
there is a lack of documentation on this use of GRASS_NOTIFY. For instance,
it is not clear to me is whether it is required or optional to set GRASS_NOTIFY
with e.g.:

export "GRASS_NOTIFY=kill -USR1 `pidof ximgview`”

for this to work as intended. Surely it is not expected a user should look for this
information in the mailing list.


>> In addressing an otherwise trivial compiler warning, I stumbled into
>> this for me strange piece of code and usage of GRASS_NOTIFY in the
>> Raster Display Library. I put up a PR [1] suggesting the removal of
>> this, but I agree with Vaclav I’d better ask here on the ML.
>> 
>> The only use of GRASS_NOTIFY is in “D_close_driver()” [2] and the
>> value of that env variable (if set) is directly inserted in a
>> “system()” call, without any sanitation!
> 
> What sort of "sanitisation" would you suggest? The variable is set by
> the user, its value is passed directly to the shell.
> 

I’d say it would be better to avoid sanitation, with what I mean making sure
GRASS_NOTIFY hasn’t been compromised, at all. Couldn’t the desired outcome
of using GRASS_NOTIFY be implemented in another way?
(It could, probably rightfully, be argued that this is not the single one weakness in
GRASS code and in addition a very unlikely attack vector, but why leave doors
open if not needed).