So ExecResult throws out shell metacharacters? I'm confused as to what
is the expected "correct" behavior so I don't get burned next time I
need to upgrade. For example, we've got commands like this:
classes:
any::
hasbluesmokeloaded = ( ReturnsZero(/bin/sh -c
${dblquote}/sbin/lsmod | /bin/grep -q bluesmoke${dblquote}) )
And it works fine. Will upgrading to 2.1.17 break these class
definitions? Luckily we don't have any shell metacharacters in any
ExecResult statements right now, but I believe I'd be as suprised as
Nathan if I did
control:
any::
bluesmokemod = ( ExecResult(/bin/sh -c ${dblquote}/sbin/lsmod |
/bin/grep bluesmoke_mc${dblquote}) )
and it didn't work, since I'm explicitly spawning a shell to handle the
metacharacters.
Paul Krizak 5900 E. Ben White Blvd. MS 625
Advanced Micro Devices Austin, TX 78741
Linux/Unix Systems Engineering Phone: (512) 602-8775
Microprocessor Solutions Sector
Mark Burgess wrote:
To have pipes you have to have a shell. But the price for having a shell
is a less certain environment for execution, in which shell environment
attacks can be used etc. That is also why the "useshell" option exists
for shellcommands. In general I try to have default behaviour as secure
as possible.
M
On Fri, 2005-11-11 at 15:13 -0600, Paul Krizak wrote:
What was preventing the pipes from working in ExecResult? I'm a bit
concerned that it was reportedly working in 2.1.15 (which is the version
we're on now), and apparently broken in 2.1.16-17...and then fixed with
a *new* command in 2.1.18cvs?
I'm not sure how running
ExecResult(/bin/sh -c ${dblquote}/bin/cat /proc/cpuinfo | grep
Processor${dblquote})
Is any different than
ExecShellresult(/bin/cat /proc/cpuinfo | grep Processor)
...or am I missing something?
This is just a convenience so you don't have to use the /bin/sh
explicitly.
M
_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/help-cfengine
