map_secondary_to_primary_gid

System

The organization is trying to determine whether to implement the map_secondary_to_primary_gid=yes with TeamSite 5.5.2 on Solaris. I don't see how we can avoid it - it's just a matter of time before at least one user is in more than 16 OS groups. But I would like to better understand the implications. Can people using this setting provide their feedback on how effective it is and what problems it causes, and those that aren't using it describe their workarounds?

I found the following articles on this setting:

https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=1486
http://devnet.interwoven.com/forums/cgi-bin/showflat.pl?Cat=&Board=PRODUCTS_TEAMSITE&Number=176&page=&view=&sb=&o=&vc=1
http://devnet.interwoven.com/forums/cgi-bin/showthreaded.pl?Cat=&Board=PRODUCTS_TEAMSITE&Number=9683&page=&view=&sb=&o=&vc=1#Post9683
http://devnet.interwoven.com/forums/cgi-bin/showthreaded.pl?Cat=&Board=PRODUCTS_TEAMSITE&Number=21270&Search=true&Forum=All_Forums&Words=map_secondary_to_primary_gid&Match=Entire%20Phrase&Searchpage=0&Limit=25&Old=allposts&Main=21170

Based on this there seem to be several issues:

1. Users other than root and iwui will see their primary group for all files which have a gid of which they are a member. File properties and iwattrib will show the correct values.

2. Attribute caching could cause incorrect allowance/disallowance to files.

3. "It will not work with hundreds of groups and is not supported under these circumstances."

4. "There may be other places where we hit restrictions imposed by the 16 group limit not addressed by this workaround. Since we are unable to predict where these may occur, this setting should be used only as a last resort with the understanding that there are significant limitations and issues. If you are unable to work within group limitations of Unix/NFS, you may want to consider using another operating system with fewer restrictions on group membership."

5. Potential performance hit.

6. Could cause OpenDeploy issues with do_deletes.

The first issue seems pretty annoying, but I think we can live with it. I am not sure if the client will accept the second issue - it seems to me that the product should enforce permissions correctly and still have good performance. Does anyone know if all edit operations in the UI use the non-caching mount point? I don't think we have to worry about users mounting or using ssh and vi to edit files, so as long as the UI enforces permissions I don't see a problem. I would like specifics on the third issue - that seems pretty vague. Four is ridiculous, it almost makes it sound like this setting and all Unix operating systems are not actually supported by Interwoven, but no realistic alternative is provided. I would also like some statistics on the performance impact (5). Anyone who understands how this would interact with OpenDeploy, please provide details.

Thanks & regards,

-John

Migrateduser

You said you're manipulating files directly through the UI, so this is just my way of griping only because you brought it up. Contrary to your setup, none of my users manipulate files through the UI - they all FTP from their own PCs. We have several dozen groups with the same members and so we had to implement this option. It's sort of worked, but not completely. Users still have trouble overwriting files that they should have every right to write over. It's baffling. They can, however, delete the file they need to overwrite on the TeamSite side and then write the file with no trouble. Weird. And working in the shell as we do makes it very annoying to see the group ownership not being right when we list the files. We've checked with our Unix sys admins and there's really no other way to get past the 16 group limit. This is the best and only option, so at least it sort of works. I don't think we've noticed any kind of performance issues, but we aren't concerned much with performance anyway.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com