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

Reply via email to