Unable to create new workflow -

We began experiencing problems with our TeamSite login process, whereby we were receiving “internal Server Error “ messages after entering in a username and password.

Only the “logout” option was visible.

I traced the problem to be related to file permissions on CGI files beneath /httpd/iw-bin to add the sticky bit for the root owner.

chmod 4755 *.cgi

(whilst logged in as root)

This appeared to resolve the problem as I was able to see the TO DO list again and continue with an EXISTING workflow.

However, a new problem has arisen whereby trying to create a new workflow is now impossible.

- Having selected a file,
- started a new WORKFLOW ( File | New Job)
- completed the description box
- Hit “New Job”

- This loaded the /iw-bin/iwwft_instantiator.cgi file

At this point the permissions of the /iw-bin/iwwft_instantiator.cgi were as follows

-rwsrwxr-x 1 root daemon 30688 Mar 12 2002 iwwft_instantiator.cgi

I received this error message in a pop-up window as TeamSite tried to build the final form before submitting the workflow:

“invalid workflow template:

insecure $ENV{PATH} while running setuid at /usr/iw-home/iw-perl/lib/perl5/site_perl/5.005/TeamSite/Config.pm line 93"

(see attahced: error1.jpg)

Here is Line 93 from that file in context:

sub iwgetmount()
{
if (defined $Config{iw_mount}) { return $Config{iw_mount}; }

my $cmd = "$Config{iw_home}/bin/iwgetmount";
if ($^O eq "MSWin32") { $cmd .= '.exe';}

(line #93) $Config{iw_mount} = `$cmd`;
chop $Config{iw_mount};

return $Config{iw_mount};
}

I thought this might be related to the chmod 4755 *.cgi command I gave earlier so I removed the ‘s’ permission from that file.

-rwxrwxr-x 1 root daemon 30688 Mar 12 2002 iwwft_instantiator.cgi

- When I tried the same procedure again I was able to get the next form page up - without the error message.
- However, Upon trying to select RUN JOB and submit the new workflow I received a javascript pop-up box stating “Invalid Workflow” and nothing else. I cannot proceed any further than this.

(see attahced: error2.jpg")

I think this has something to do with the permissions of other CGI files in the /httpd/iw-bin folder. However, I do not know what the correct permissions, owner, group etc… should be for each file.

I still think there may be a problem with iwwft_instantiator.cgi file and subsequent files which are called afterwards.

Please can you firstly tell me what should be the correct permissions for all files in the /httpd/iw-bin folder. ?? Perhaps a directory listing from your TeamSite test box ??

We are currently running TeamSite 5.0.2 on SOLARIS 8

Secondly, which files are called after iwwft_instantiator.cgi ? and what should there permissions be.

Please help me with this as I have spent the past 5 hours trying everything to fix it but to no avail.

I have attached screen shots of the 2 error messages i am receiving.

many thanks for any help anyone can give.

John.

Edited by JSB on 09/18/03 06:49 AM (server time).

Find more posts tagged with

Comments

JSB

Attaching second JPEG - error2.jpg

Migrateduser

If you ack the alert and view source on this instantiator form with the error is there a more descriptive error message in the JavaScript somewhere?

Also look in the .wft for die calls with no error message.

JSB

Hi,

thanks for replying so quick.

I have attached a text file which is the source code of iwwft_instantiator.cgi after the javascript error appears. doesn't appear to be very helpful Smiley Sad

It appears that the form is being resubmitted back to itself upon submission.

How do i do what you suggested and look for "die" calls in the .wft ???

thanks again,

john

Migrateduser

You're right, that HTML source is not very useful.

- look under IWHOME/local/config/wft for the .wft file that is being invoked here and grep through it for die calls. I usually use die in the .wft when there is some condition in the data that precludes the content being workflowed, but it should be passed an error message (maybe it is an empty variable in this case, or a typo). I would look through the .wft file for any calls to die. You might also check any Perl modules it is calling.

I think the next step is to add logging to the .wft to see where it is failing.

If you can post the .wft someone may be able to help. I guess it's possible that it's not generating any XML at all?

Did this start happening after some change to code or configuration, are you migrating to a new server or version or what?

It is normal for the form to submit to itself.

You could always try sending the .wft to support too.

james1

I would strongly urge you to remove the sticky bit from the programs that are not required to have it. Who knows what unexpected behavior (and security holes) you may experience as a result?

-- James

--
James H Koh
Interwoven Engineering

JSB

This all seems to have happened rather unexpectedly.

the only thing I have changed recently was the permissions of the CGI & ITML files beneath the <iw-home>/httpd/iw-bin folder to add / remove the setiud 's' permission to run as root.

I have not touched the .wft at all so I am confused as to why this is happening. I feel certain it is a strange permissions thing but cannot put my finger on it.

Will try and upload the .wft file as well.

Thanks,

John

mgal

For the "invalid workflow" error message you might get more useful information from the iwtrace log file (/var/adm) or iwjoberrors.log file.

nipper

Why did you set the sticky bit ?

That caused your problem, when a perl script is run as setuid, it runs in taint mode. It is very restrictive.

go here if you want more on taint mode:

http://gunther.web66.com/FAQS/taintmode.html

On my system this is not setuid:

-r-xr-xr-x 1 root daemon 32470 Mar 24 03:16 iwwft_instantiator.cgi

Though some of the files are:

nph-iw_cgi_wrapper.cgi, wrlistwrap.cgi, iwrlist, iwrcopywrap.cgi, iwrecover.cgi, iwrcopy, iwmerge.cgi, iwfileupdownload.cgi, iwfsckcgi.cgi, iwcgi.cgi, iwbsdiff, iw_cgi_wrapper.cgi

I assume you had a process that ran & removed the sticky bit so you tried to reset them

Problem is that you cannot just set all of them

You may need to rerun the config portion of the install script, whatever goes through and chmods, chowns iw-home

Hope this helps

Andy

JSB

Some more info.

here is the chunk of code from iwwft_instantiator.cgi which creates the javascript error message:

my $wf_system = TeamSite::WFsystem->new();
my $wf = $wf_system->CreateWorkflow($spec,$wf_tmp,$nest);

if ((!defined $wf) || !$wf->IsValid() || $wf->GetError())
{
my $err = $wf->GetError(); $err ||= "";

# not doing a callback here because sometimes the
# problem is just bad userdata (which can be cleaned
# up & the sumission can be retried)

display_input_form($wft,$cgi, "Invalid workflow:\n$err");
exit;
}

i have also attached the complete iwwft_instantiator.cgi file for reference.

John.

JSB

Hey Andy,

thanks for your comments.

The reason I set the sticky bit on this file was because without it I got this error message:

“invalid workflow template:

insecure $ENV{PATH} while running setuid at /usr/iw-home/iw-perl/lib/perl5/site_perl/5.005/TeamSite/Config.pm line 93"

(see attahced: error1.jpg)

I have not changed the Config.pm so didn't think this would be the cause of it.

any ideas how to resolve this error message?

cheers again,

John

nipper

>insecure $ENV{PATH} while running setuid at /usr/iw-home/iw-perl/lib/perl5/site_perl/5.005/TeamSite/Config.pm line 93"

I think you got this message AFTER you setuid'd the file.

That is a message you get when you are running Perl in taint mode. If you remove the setuid on that file, that specific error shoudl go away. As I stated on 552 SP3 on Solars 2.8 it is NOT set on my system here.

Only a handful of the cgi in iw-bin on my system have the stick bit set.

Andy

Adam Stoller

At this point I'd recommend that you uninstall and reinstall TeamSite and TeamSite Templating (assuming you had it installed) - but changing the bits on ALL the files in the directories that you did - you have invariably broken pieces of the product as only *some* files are supposed to be setuid root.

Alternatively, perhaps faster, but also perhaps more error prone - look at documentation in the manuals and on the Support site for a list of exactly which files need to be setuid root and remove the sticky bit from *every other* file.

--fish
(Interwoven Senior Technical Consultant)

nipper

I tend to agree with Fish, but since I am also lazy I would probably just try changin these files:

httpd/iw-bin/iw_cgi_wrapper.cgi
httpd/iw-bin/iwbsauth.cgi
httpd/iw-bin/iwbslogin.cgi
httpd/iw-bin/iwcgi.cgi
httpd/iw-bin/iwfileupdownload.cgi
httpd/iw-bin/iwfsckcgi.cgi
httpd/iw-bin/iwmerge.cgi
httpd/iw-bin/iwrcopy
httpd/iw-bin/iwrcopywrap.cgi
httpd/iw-bin/iwrecover.cgi
httpd/iw-bin/iwrlist
httpd/iw-bin/iwrlistwrap.cgi
httpd/iw-bin/nph-iw_cgi_wrapper.cgi

That I read from iwinstall on TS 552 SP3 (check your file), there is a variable called SUIDROOTFILES that lists the files.

Of course there is probably somthing else hosed, so a reinstall will likely be required.

(glad it is not my system),

Andy

JSB

Thanks to everyone for responding so quickly.

fish - yes i agree that changing all the files to setuid was a mistake. what confuses me is that having realised this, I removed ALL the setuid bits from these files and then reapplyed them only to the files that were listed in Tech Note 2234:

TechNote: 2234 Title: Files Required to Be Setuid in TeamSite 4.5 - 5.5.2Date Created: 2001-07-13 10:33:57
Date Modified: 2002-10-29 14:27:32
Synopsis:

Teamsite requires certain files to be installed setuid-root. If permissions are accidently changed you can use this KB to restore them.

Details:

The following files all need to be setuid for proper functioning in Teamsite. This is done by default during the installation but if permissions are accidently altered you can double check against this list by cd'ing to iw-home and typing find . -perm -4000

iw-home/httpd/iw-bin/iw_cgi_wrapper.cgi

Needs to be able to do setuid/setgid to impersonate user while running downstream cgi.

iw-home/httpd/iw-bin/iwcgi.cgi

For the SetHome feature, needs to write to <iw-home>/local/iwprofileswhich is owned and write able only by root.

iw-home/httpd/iw-bin/iwmerge.cgi

Needs to impersonate user to write files on their behalf
iw-home/httpd/iw-bin/nph-iw_cgi_wrapper.cgi
nph-iw_cgi_wrapper.cgi is really a copy of iw_cgi_wrapper.cgi. Some customer(s) want to run non-parsed-header cgi scripts via the custom cgi hook mechanism.

Having done this I was able to login, but clicking on the To Do button gave the same "Internal Server Error". Therefore I added the setuid bit to this CGI file:

<iw-home>/httpd/iw-bin/iwwftodo.cgi

and the To Do button worked again. That is the stage we are currently at, with only the correct files + the iwwftodo.cgi file with sticky bits set. yet I still get the "invalid workflow" pop-up.

Andy - you are correct about when I receive that Perl error. if I remove the setiud bit from iwwft_instantiator.cgi then I get the invalid workflow error message.

I am planning on getting a copy of our <iw-home> directory from 7 days ago from our UNIX support team from backup tapes.

I plan to compare the permissions of files from this copy with the existing ones.

Can anyone tell me what the implications are on potentially restoring the entire / portions of the <iw-home> dir and sub folders from a backup?

Thanks again for everyone's help.

John.