[GRASS-dev] Question regarding GRASS_NOTIFY

[Nicklas Larsson]

I have finally had the time to take a little better look at the code and actually test
ximgview/wxpyimgview. I replaced my first PR [1] for deleting GRASS_NOTIFY
with a PR [2] with which a G_warning is issued if the system call fails.

The documentation on using ximgview/wxpyimgview, including the signal handling,
could probably be improved. I will at least file a ticket with that aim.


Thank you Glynn for jumping in on this, I very much appreciate it!



[1] https://github.com/OSGeo/grass/pull/2135
[2] https://github.com/OSGeo/grass/pull/2705



> On 4 Mar 2022, at 20:28, Glynn Clements <glynn at gclements.plus.com> wrote:
> 
> 
> Nicklas Larsson via grass-dev wrote:
> 
>> 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.
> 
> I think that it's "expected" that the user will just use the GUI.
> 
> It seems doubtful that anyone (other than me) actually used this. I no
> longer actively follow GRASS; I only remained subscribed to the list
> for cases (like this) where someone is asking about arcane details of
> stuff I worked on in the past.
> 
>>> 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?
> 
> Well, it could be made a GRASS ($GISRC) variable. A fixed command name
> could be inconvenient if you have multiple GRASS sessions in different
> shells (again, I don't think this is "typical" user behaviour). It
> could use some other mechanism entirely (e.g. a filename identifying a
> socket or named pipe to which D_close_driver would write) would work,
> but would be a non-trivial effort for something that probably isn't
> even used.
> 
> I'm not sure manipulating GRASS_NOTIFY gets you much compared to
> manipulating e.g. EDITOR or BROWSER. And unless there's been a
> significant effort on security since I was active, using GRASS with
> untrusted inputs or an untrusted environment has much bigger issues.
> 
> In any case, ximgview/wxpyimgview don't appear to have had any
> substantial changes or issues (i.e. nothing that doesn't appear to be
> a repository-wide clean-up) in the last decade, so non-GUI usage of
> the display subsystem is probably a non-issue at this point.
>