Re: modules bug with pre-scanning for a user

[Mark . Burgess]

On 12 Jun, Ted Zlatanov wrote:
> Mark.Burgess@iu.hio.no writes:
> 
>> This is expected behaviour if the JoeFound class is defined. There have
>> been bugs related to class definition, but I'm not sure what is the
>> problem in your case. My tip would be to use your orginal idea, but like
>> this to remove the output
>> 
>> groups:
>>  JoeFound = ( "/bin/grep joe /etc/passwd >/dev/null  2>&1" )
> 
> I forgot to mention that I had tried that already:
> 
> groups:
>   JoeFound = ( "/bin/grep joe /etc/passwd >/dev/null" )
> 
> But I get the error:
> 
> grep: can't open >/dev/null
> 
> So you are interpreting the > yourself, rather than passing it to the
> shell.  I'm not sure where to look in the source code to dig further.
> 
> The original problem that I had was that, even if a files: command is
> conditional upon an AddInstallable class defined by a module (thus, in
> an unknown state at first), it will be checked for username validity
> regardless of whether the conditional class is really defined or not.
> I hope that explains it better.
> 
> In C lingo it might be clearer:
> 
> char JoeFound; /* the class */
> AddInstallable(JoeFound);
> 
> JoeFound = ask_module_if_Joe_Found();
> 
> if (JoeFound) check_files("/home/joe", "owner=joe");
> 
> The problem is that the owner=joe parameter to check_files is getting
> checked for validity against /etc/passwd regardless of whether
> JoeFound was true or not.
> 
> It's not a critical bug for me, but I'd like to use modules in
> conjunction with a database to download dynamic rules applicable to
> certain machines.  If module-defined classes have funny evaluation
> rules vs. hard-coded classes, I may have to rewrite the cf.classes
> file dynamically instead - not a worse solution, but I'd rather have
> clean integration between cfengine and my software.
> 
> Thanks
> Ted


Ahh... that might be due to a change that I made to remove shell
execution... I hadn't thought about that issue. I was thinking
of security...strictly speaking I don't see why this cannot be
changed now...I shall look into it.

Mark

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~