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. _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
