[GRASS-dev] Question regarding GRASS_NOTIFY

[Glynn Clements]

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.