Wrong permission on new files and folders

Hi Experts,

I've got the following problem with teamsite 5.52:
Sometimes (not always) when a user creates a new file or folder in his workarea and submits this new item, the file/folder gets wrong access rights.
The user who created the file, gets r/w/x, but the assigned group gets only r/x.
In the iw.cfg file the following settings are available:
branch_security=on
workarea_security=on
branch_default_perm=770
workarea_default_perm=770
file_default_perm=770
directory_default_perm=770
(I hope these are the required ones...)

Does anyone have an idea where I have to set the permission additionally to get the correct permission on new files and folders?

THX

Find more posts tagged with

Comments

Adam Stoller

What platform?

If Unix - check the umask of the user "iwui" - I believe that this umask value gets applied to the permissions requested in the iw.cfg (though one would think you'd get a consistent result..)

--fish
(Interwoven Senior Technical Consultant)

benja78

yes,
it's a unix system. I'll check the umask of this user out tomorrow!

Thx
benjamin

benja78

...sorry, but I've got an additional stupid question.

The umask of all 'normal' users will be set in theire profile. file in theire home directory. As far as my solaris knowledge goes, I can't find a .profile file for the iwui user.

Is there any other way to check the umask of the iwui?

thx in advance
ben

KTR

Could you pls share the solution for this problem, I do have the similar problem. When I generate HTML/XML thru formAPI callServer call, it generates page successfully with following permissions,
user name: iwui
group : nobody

664 -- we can change this by updating iw.cfg, but, I would like to have
user name : user who logged-in and genearted page
group : user group( belonging to pagecreator)

Any help is appreciated.

best regards,
KT

nipper

Not exactly what you asked for, but you can make iwui part of the group that owns the Workarea. Then the users
will have write access. Once the file is submitted, submit.cfg will take care of the permissions.

Andy

KTR

We did this temp. but, I want to see my name as user and my group as group name ( now, I am able to se only iwui as user and nobody as group, which I did't like!!!) for that HTML file. Is there any way I can get it done.

Thanks,
KT

Valentine

it is /etc/profile. It is being executed right before $HOME/.profile.

Adam Stoller

Does the CGI program being run through the callServer() function get passed any information about the user who was editing the DCT/DCR? If so - then you can make chmod()/chown() calls within that CGI to set the protection/ownership bits the way you want them. If not - then you need to open an enhancement request through support to provide for that information being passed over (and possibly to have it behave as such to begin with).

Another possibilty - since I believe you need to provide the URL for the callServer() - is to use the iw_cgi_wrapper.cgi/yourcgi.cgi technique - and that *might* do what you want.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

KTR

I am using this and still it's not solving my problem
var url = "http://"+server+"/iw-bin/iw_cgi_wrapper.cgi/generatePage.cgi";
I also tried chmod and chgrp cmd's in cgi and not working, but, I am able change the the mode to 775.

nipper

>I also tried chmod and chgrp cmd's in cgi and not working

chown is pretty funky on Unix. It only works reliable for root.

even though the man page reads:

Only the owner of a file (or the super-user) may change the
owner of that file.

when I create a file & try to give it to someone else I get the error:

chown: hi: Not owner

chgrp should work if iwui is part of destination group.

Andy

KTR

You are right. I can't even run chgrp cmd, even the "iwui" is in my group.

KTR

I am sorry, instead of saying chown and chgrp, I said chmod and chgrp (chmod works fine).

nipper

>You are right. I can't even run chgrp cmd, even the "iwui" is in my group.

of course I am right. Did you doubt me ?

For chgrp to work you need to own the owbject & be a member of the destination
group (and maybe source group as well).

Since iwui owns the file, make certain iwui is part of the destination group and
see if your chgrp works

or just make iwui's primary group the group you want to own it (if this is the only
project on TeamSite)

HTH

Andy

KTR

Does any one has idea on STICKY BIT part on custom script (unix), pls share with me.
I think, if I change the owner of my script as "root" and apply STICKY BIT on it, it should run any cmd in that script ( chgrp, chown and etc...).
So, I feel to take EXPERTS suggestions on this and want to make sure, I am in right direction. PLSSSS reply me.
Thanks,
KT

Adam Stoller

setuid and sticky-bit are two different things.

setuid (chmod 4755) means that the script is run as the owner of the script - and it's generally a security hole which, if you're using Perl, you have to go through the whole taint process.

sticky-bit (chmod g+s) is usually applied to directories - to enforce that files created within those directories are given the same group-ownership as that directory, regardless of the primary group of the user who creates the files within.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

nipper

>sticky-bit (chmod g+s) is usually applied to directories - to enforce that files created within those directories are given the same group-ownership as that >directory, regardless of the primary group of the user who creates the files within.

You can do this, but it will still be easier to change the group that iwui belongs to. With the sticky bit you need to set that
bit on every directory in the system.

Also make certain you are using submit.cfg. That makes like easier.

Andy

AKB

You can do this, but it will still be easier to change the group that iwui belongs to. With the sticky bit you need to set that
bit on every directory in the system.

Changing group will solve one problem and that is access to the files generated. The other problem is the owner of the file. I think if I read it correctly the owner of the file comes as iwui where as it should come as the person who is generating the page....

AKB

Another possibilty - since I believe you need to provide the URL for the callServer() - is to use the iw_cgi_wrapper.cgi/yourcgi.cgi technique - and that *might* do what you want.

If any one who has used iw_cgi_wrapper.cgi/yourcgi.cgi successfully to "wrap the user" (so that actual owner who has generated the file owns the file instead of Iwui). please pass on some steps/ code snippets as how it was done...

I think the aim is that when the file is generated in the "modified by" column beside the fileName the owner name should come instead of iwui...

nipper

>Changing group will solve one problem and that is access to the files generated. The other problem is the owner of the file. I think if I read it correctly the >owner of the file comes as iwui where as it should come as the person who is generating the page....

2 points, if group write permission is set, then it does not matter if the person or iwui owns it.

Also, this only matters for a file that has not been submitted. Once it goes to Staging, submit.cfg will change the owner/perms to
whatever is configured.

nipper

>I think the aim is that when the file is generated in the "modified by" column beside the fileName the owner name should come instead of iwui...

That is a pain, we have way too many files modified by iwui

AKB

yeah that is pain .....even if we use submit.cfg to change the permissions etc..the person who modified the file ...his name will never come and all the files will have iwui..in the modified by...column...

AKB

Sorry KT but this looks more like the scenario(from one of my previous project) where iwpt_compile.ipl Perl script is used to generate or regenerate templated output via a workflow ExternalTask. The regenerated page gets "modified by SYSTEM" (OS was Windows) where as it should show the user who last modified the DCR
Since workflow ExternalTask processes run as SYSTEM, the last modified value shows the user SYSTEM...

Interwoven at that time made it a feature request.....