On 8/15/07, Cameron Simpson <[EMAIL PROTECTED]> wrote: > On 14Aug2007 19:11, seventh guardian <[EMAIL PROTECTED]> wrote: > | > > > Running FvwmCommandS is a security exposure. > | > > > Some users might be reluctant to use it. > | > > > | > > I don't use FvwmCommand because it's too slow. [...] > | > > I do not want to start an executable every n seconds [...] > | > > | > You missed my point, I'm not using FvwmCommand, but only FvwmCommandS. > | > FvwmCommandS creates two fifos that can be used to send and receive > | > text to/from fvwm. So instead of calling FvwmCommand, you can directly > | > write commands to the command fifo. So really NO overhead at all. > > | > As for the security issues, they can easily be circumvented by putting > | > the fifo in the user home dir. > > (Or somewhere else well controlled, for users with home dirs over NFS, > like me at my workplace). Anyway, your point is taken - the user can do > it securely, BUT ... > > I was fiddling with modules some time back and found the FIFO > locations... unpredictable. There's a bunch of logic in the module setup > code to decide where the FIFOs go. I am very firmly of the opinion > that the user should have a hook to override all of that and _directly_ > specifly the FIFO location. From what I remember of the code, that's not > as straight forward as I'd have expected - FIFOs appeared as a side > effect of calling the setup code and didn't even get reported back to > the caller if I recall correctly.
You're right, they follow a logic put in fifos.c, and allowing the user to specify a new location isn't straight forward. If you ignore the security issues of not allowing a user to specify the fifos' location, there's an easy way to let the user know where they are: simply add a new cmd line option to FvwmCommand to reveal their location. This way a "script module" user would only need to call FvwmCommand once at the start of the script and then store the fifos' locations in a variable. Cheers, Renato
