Aren’t ClearCase triggers kind of broken???
ClearCase triggers are supposed to force the users to follow the policy. They need to be laying at some tamper-proof location, so that nobody tries to short-circuit them. Right? Sort of…
A small exercise.
Let’s first make an unfriendly trigger.
print "Sorry, this trigger is always false!n"; exit 1;
We’ll make it a pre-checkout trigger.
Try it:
Works as expected.
Now, I can’t modify the trigger (tamper-proof, remember :-D), why not wrap around ccperl.exe? Sorry for not doing things elegantly, it’s just an example:
/*******************************************************************************
* *
* This thing does almost nothing. If it's not called as a trigger it just *
* calls ccperl2.exe with the same arguments. If it's called as a trigger. it *
* returns true *
* *
*******************************************************************************/
#include <process.h>
#include <string>
#include <stdlib.h>
#include <iostream>
using namespace std;
int main(int argc, char *argv[])
{
string perlcall("C:\Progra~1\Rational\ClearCase\bin\ccperl2.exe");
// pass all arguments to the script
for (int i = 1; i < argc; i++)
{
perlcall+=" ";
// Put back quotes...
if (string(argv[i]).find(" ",0))
perlcall+="\""+string(argv[i])+"\"";
else
perlcall+=argv[i];
}
int retVal= system(perlcall.c_str());
if (getenv("CLEARCASE_TRTYPE_KIND") != NULL)
{
cout << "Well, now it's always true!!!" << endl;
return 0;
}
else
{
return retVal;
}
}
Of course, I could just have it return 0 without executing the trigger, but then, the screenshot below would be less self-explanatory ;-). So now, let’s rename ccperl.exe to ccperl2.exe, and use our fabricated ccperl.exe instead. Let’s see how it works.
And that’s it.
Sure that’s just one more thing to remember - don’t give users the rights to modify ClearCase bin directory. But if triggers are supposed to force user to do something, why is there’s no checking, whether ccperl.exe is really ccperl.exe and not some kind of a lousy wrapper?
