Separating Prod from non-Prod source access with Mincomcm user 1

[sjwales]

I was wondering if anyone has managed to separate Production source access from Development / Test / Whatever through Mincomcm. We have everything on the same machine (HP Superdome) and the auditors were less than pleased to find that all of the programming staff has access to production source code.

Rather than re-invent the wheel in some way to limit access to production source to a small set of authorized users, I'd like to solicit input from this forum to see if anyone else has had this issue and developed a work around.

We have a call in with Mincom, but haven't heard back from them yet.

Thanks
Steve

stephen.wales@riotinto.com

 

[dianne001]

Hello Sjwales,
Auditors are quite picky when it comes to programmers modifying production code. The Auditors are usually not so concerned with someone being able to read source code. They are more concerned with people modifying source code, i.e. who has the capability to modify code. Since all of your environments are on one box, One thing you might want to consider is changing the permission's on the directory for your production code to be only read for everyone. This would prevent any problems with modifying production code. The problem/inconvience comes when updates to production code have to occur. then you have to reset the permissions to read/write and then put it back to read when your done. The only other thing is if you have a lan that you can store all of the source code on and limit the access to the lan. That way you always have a complete production copy.

Hope this gives you some ideas.
Thanks,
Dianne

 

[sjwales]

We could do that, I suppose, but since mincomcm owns all the source code (prod and non-prod) it wouldn't be real hard to have the programmers change it back. Not that we don't trust them, but the auditors don't, apparently

Along those lines we could change the owner and permissions, but as you say, that would require me or the other sysadmin to get involved every time the programmers needed to promote a work order to production. That doesn't seem very efficient to me.

Hmmm, we will need to continue pondering this one, I think.

Thanks for your reply.
Steve

stephen.wales@riotinto.com

 

[Glen]

Steve,

Is mimcomcm a group ID or some new mincom migration tool?

Glen Colbert
gcolbert@rag-american.com

 

[sjwales]

Source management has changed between Ellipse and MIMS Open Enterprise 4.x. Instead of having a unix user for each Instance, you have mincomcm which is for all source code management and then have a run time instance user for each run time instance.

Only problem is, with only one source code owner, it owns *everything* and we've not yet worked out a way to separate prod from non prod sources.

And if you have multiple productions, for multiple companies, no way to split them out either.

It's an all or nothing kinda deal.

Steve

stephen.wales@riotinto.com

 

[blakej]

I found that mincomcm has defined in the syscfg.xml file,
but alas since that is common per machine all environments will use it.
If you dont use eac much, I guess there would be no problem having the code owned by different users, and removing the group access for prod.
There is also the option of making the prod code a "development" version (check the fine print in the doc)
instead of the default "production" setting.
I think this means source and instance can be owned by the same account. It defeats the Mincom model but at least auditors may be happy (as long as the instance account is secure).

 

[MikeLeung]

Just change the ownership of the source directory and the files within it to another user. The user that owns the source files has to be a member of the mincomcm group (755 permission).
The only user which can change the files will be the owner.
Members of the mincomcm group will be able to read the files.

This is the mincom model. mincomcm is just the default owner. If you read the documentation or do a technical training course you will find this out.