modified by SYSTEM

Ive been told that workflow external tasks run as SYSTEM.
So if it creates or touch files, its stamped at the SYSTEM user.
This does not happen on Solaris.

Not sure if this is the same problem for you, but Im hoping IWOV will come back to me with a workaround for this.

It would be great to hear from anybody here that knows more about it

Thanks

John Cuiuli
Sydney, Australia

Yeah, this is one of those things about TeamSite on Windows that "rocks" - anything that is touched by workflow (like, say, all templated output, or anything that has an extended attribute set on it, which means basically everything) shows modified by SYSTEM. I requested they add an iwattrib parameter that lets me explicitly set the last modified user (since I am pretty sure this is an IW attribute, not an NTFS attribute), but I am not aware of any progress on this issue. As always, the more customers that request something the more likely they are to fix it, so please file a feature request. Since it's always the useless/inaccurate SYSTEM I wish I could remove that column from the UI, but this also is not possible without some hacking.

One thing that might help is to set an extended attribute that shows who really last modified the file. As the first step in whatever automted process is running as SYSTEM you can use iwattrib to determine who last modified it and set the attribute (unless, of course, iwattrib returns SYSTEM). Then it is available in file details, but the UI will still show SYSTEM.

I was really surprised to find this happens on windows.

It is such a common thing to have workflow generate/set attributes etc.

I sure wish I was using Solaris again. I cant believe how many problems I have run into on the windows platform.

John Cuiuli
Sydney, Australia

I think i will file for a feature request on this one.

Id be surprised if there isnt one already.

John Cuiuli
Sydney, Australia

nico

Wow didn't realize how pervasive this was, thought it was isolated to my situation. Definate feature must have upgrade.

Really strange though as my environment was not behaving this way until just recently, ack.

Nico

iwovGraduate

I am having this issue with TS 6.1 on W2K for file that are modified via a wrokflow externaltask.

The workaround of setting the extattr with the actual user works for scripts, etc., however in the UI users don't see that unless they go to view properties. The users are not thrilled about this.

Is there a workaround for this ?
Does anybody have a FR # (actually should be a bug #) for this ?

Edited by iwovGraduate on 01/31/05 10:50 AM (server time).

Any updates on this issue? The behaviour is still the same as of 6.5SP2. Haven't checked it on a 6.7 box yet.

Sailesh

Since teamsite requires higher permissions to run external tasks, it always require SYSTEM (for WINx) or root (solaris) access.

Only way out is set extattr.

Adam Stoller

Since teamsite requires higher permissions to run external tasks, it always require SYSTEM (for WINx) or root (solaris) access.

Only way out is set extattr.

Yes - but on Unix there is seteuid functionality so that the process is run "as" the logged in user and it is the logged in user's id that is associated with the submitted files.

Windows has a "runas" command - but it requires interaction to supply the user's password (as far as I can tell) and therefore cannot be used in the same manner - thus the submitted files are associated with SYSTEM because that's the id associated with the process.

Maybe when Looooooonghooooorn gets released it will provide seteuid functionality - but the way that release has been going, I wouldn't be holding my breath ;-)

Sailesh,

iwextattr wouldn't help. The modified by is a native attribute (lastuser), not an extended attribute. Since iwattrib doesn't have a -s flag to allow you to tweak the attributes, there's no CLT way to fix the problem.

I guess the root issue is that windows impersonation, which is the same basic concept as setuid, just differently implemented (I say differently rather than worse, because I think one could make a case for the way they did it even though I don't like it), requires passing the user credentials when you begin the impersonation. So, I guess to accomplish the same functionality on windows, IWOV would have to cache the user's password in the cookie or something. And that would be a Bad Thing.

It seems like, however, the last user to touch the file must be stored as an attribute of the ntfs inode. I looked around the net a little to see if I could find decent enough documentation on ntfs to verify that, but nothing came to me. I would think that one could build a workaround though, where the iwserver process would tweak the attribute based on info passed to it in the RPC. Then again, I am definitely not a filesystem engineer.

Sailesh

Seems there is no way out of this as of now..

pondered over various way around and consulted other expert but ...

Is Interwoven planning to take this as an issue?

samstephens

So this has been an issue for three years, with no resolution ! Is this yet another case of a product engineered for Unix, and then "ported" to Windows in a half useable form as the product hasn't really be designed so it'll fit in the Windows environment.

And is a major problem, depending on how you use the system. See also http://devnet.interwoven.com/forums_vb/showthread.php?t=8384&page=1&pp=10

I'm in the boat where I need to use CCStd, and the Work In Progress portal. But if a file is touched in a workflow, and then the workflow ends (e.g. the file is rejected), the file is not in the users WIP, which is terrible.

I'm hoping I can reengineer my workflows so all changes by system happened after the files are approved and WIP doesn't matter anymore.

Even if I can fix my workflows, this issue is still **** for my users - SYSTEM isn't the last user to modify the file, the user who started the workflow is.

Where is the comment from Interwoven on this three year old thread?

Where is the comment from Interwoven on this three year old thread?

Right here. Not that you (or anybody else) would like it :-(

samstephens

Right here. Not that you (or anybody else) would like it :-(

Oh dear... well that certainly answers my question. Thanks.

nipper

But that does bring up a point. Are there any good impersonation modules for Perl that run on DOS ? Unix supports that already. If one could make a perl module that would do it, then you could use that in the external tasks.

Ghoti any idea ? Why not write one ? You have all weekend. :-)

Andy

But that does bring up a point. Are there any good impersonation modules for Perl that run on DOS ? Unix supports that already. If one could make a perl module that would do it, then you could use that in the external tasks.

Ghoti any idea ? Why not write one ? You have all weekend. :-)

Andy

Jokes aside...On XP/2003 System account is mapped to UID 0. Therefore, it has permission to execute seteuid
thus setting effective UID of the calling process. Unfortunately, that means for example that C/C++
external task wrapper won't help - wrong process! If somebody knows MS DLL that implements seteuid in any guise
I *may* be able to write a Perl call with win32::API.

Here is the synopsis:
#include <sys/types.h>
#include <unistd.h>
int seteuid(uid_t uid);

I think there's a little more to it. If it was clear enough then IWOV probably would have it by now.

Windows processes need a security/session token to run which is a concept that setuid / unix does not have. Only a username/password can generate a token.

I think with the addition of non OS users (not sure if that's in 6.7.1 or in the next release) - this problem will be solved as there will be no need to stamp files as a real OS user.

Jokes aside...On XP/2003 System account is mapped to UID 0. Therefore, it has permission to execute seteuid
thus setting effective UID of the calling process. Unfortunately, that means for example that C/C++
external task wrapper won't help - wrong process! If somebody knows MS DLL that implements seteuid in any guise
I *may* be able to write a Perl call with win32::API.

Here is the synopsis:
#include <sys/types.h>
#include <unistd.h>
int seteuid(uid_t uid);

I think there's a little more to it. If it was clear enough then IWOV probably would have it by now.

Windows processes need a security/session token to run which is a concept that setuid / unix does not have. Only a username/password can generate a token.

I think with the addition of non OS users (not sure if that's in 6.7.1 or in the next release) - this problem will be solved as there will be no need to stamp files as a real OS user.

Well, IWOV did not have it 3 years ago and it does not have it now.

As to security token, I was proposing to change Effective UID (EUID), not UID.
Two Windows Accounts (SYSTEM and Administrator) are allowed to do that under their own UID tokens.
So, I *think* that from WF Engine process I would not need the login info to impersonate another user.

ccprofessional

Looks like this feature (execute external tasks as logged in user) has finally been added in TS 6.7

There's also a workaround to allow external tasks to be executed as SYSTEM.
KB# 55773

Looks like this feature (execute external tasks as logged in user) has finally been added in TS 6.7

There's also a workaround to allow external tasks to be executed as SYSTEM.
KB# 55773

Later KB# 57278 (2006/12/13) blatantly contradicts it. It also states that "This applies to all supported versions of TeamSite on all platforms".

Have anybody tried that on Windows 6.7.x? What's your experience?

We upgraded to TS 6.7.1 two months ago. We are using Win2k3 server.

The good news is, if you set your external task owner to be a real user instead of SYSTEM, and in the external task modify an EA on a file, the file is shown as modified by the real user, not by SYSTEM as in previous TS versions.

I was thrilled initially about this, then I realized that it does not solve all the problem. It workes only if in one job, you only attach files modified by THE SAME user. Say you are an editor, you submits 10 files last modified by 10 different authors in the same job, if the external task owner is set to the editor, after the external task, all files will be shown as modified the editor. You still lose track of who originally modified these files!

Unless, within the external task, you create 10 different external tasks, each with a different owner. Then what if you submit 500 files in one job? It gets really ugly. Anyone has better suggestions?