Page 1 of 1

Making some components in Dev Environment as Read-Only

Posted: Sun Oct 04, 2015 9:24 pm
by synsog
Hi,

We have a requirement where we need to make some components in our development environment as read-only. E.g. some parameter sets, shared containers etc.

I tried exporting these codes from higher environments and importing in development environment by changing the read-only flag in the dsx. But this does not serve the purpose as if someone gets the export and overwrites it, the the component is not read-only anymore.

Is there a way to make only certain components as read-only in development environment such that those cannot be overwritten(re-imported) and cannot be changed by all users.

Thanks

Posted: Mon Oct 05, 2015 8:50 am
by PaulVL
Parameter sets:

Log in to unix and CHMOD 640 the parameter file in question (.../project path/ParameterSets/<parametersetname>/<value file>. The owner of the file should be your dsadm user id so that only the admins have writes to modify the file.


Shared Containers:

Not a wise idea to mark them read only. You technically don't have Read/Write control at a job level in datastage. It can be controled at a project level with a protected project. I would not muck around with file permissions at the shared component level. You could run a shared component validation script that would examine the last modified timestamp and who modified it and smack them... Just make sure you have a gold copy of those items in case you need to restore the orriginals.

Posted: Tue Oct 06, 2015 2:07 pm
by synsog
Thanks Paul

I changed the permissions to 640 on the value files of the parameter sets and parameter Set and observed that dsadm id is not able to access that parameter set while running the job.
So I changed it to 740. Now the job executes fine but import is also successful on the parameter set. We do not want any user to modify or import(over-write) this parameter set. Is there a way to achieve this?

Posted: Tue Oct 06, 2015 2:54 pm
by PaulVL
The owner of the file should always have write authority.

Ensure that none of your users are running jobs or have access to your dsadm user id (credential mapping).


The execution of a datastage job needs to have READ access to that file, not write. So ... can you paste the error message you see when you did the 640 setting?

Posted: Mon Oct 19, 2015 8:48 am
by roy
Hi Guys,

As a friend used to say:
"You can't protect from the keepers"

You can use in another project the sesitive componnents and export (in read only if you like) the executable only to import in the desired project.
Then it should be safe from change since they have not the source code.

As for the chmod command, I don't recommend starting to restrict the access in the OS level for individual componnents, for various reasons.

Having said that, the chmod will use a binary representation of the 3 sets of digits representing a RWX conotation of Read, Write, eXecute permitions for each of the 3 levels of Owner, Group member and Other
so a 640 is transleted to 110100000 in binary representation
the first 3 digits 110 means the owner will have Read,Write,No eXecute permitions.
The group members (100) will only have Read permitions and other users (000) will have no access to the file.

Having that said, a chmod 550 should result in Read+eXecute to both owner and groupd members but render the file not edit-able.

bare in mind that if you use the root password you have all the access to everything regardless... (if not you can always change it)



IHTH (I Hope This Helps),