Results 1 to 2 of 2
Hi everyone! Here's the scenario: I have DB2Connect on a server (default users db2inst1, db2as, etc created) which has many apps that connect to a remote DB2 server by programs ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 12-05-2010 #1
- Join Date
- Jan 2009
restrict db2 command
Here's the scenario:
I have DB2Connect on a server (default users db2inst1, db2as, etc created) which has many apps that connect to a remote DB2 server by programs made in JSPs/Java in Websphere by various users (type 2 driver).
I have recently noticed that there are users who are making attempts to connect to unauthorized databases of the external server by using the /home/db2inst1/sqllib/bin/db2 command, and I want to restrict that command so they won't keep using this method.
Currently, this db2 command, among the others created during the DB2Connect installation, have the following permission:
-r-xr-xr-x 1 bin bin 14142 Nov 27 2000 db2*
So, anyone can execute this db2 command and try to connect, list, or whatever they want with this command.
I was thinking in chmod'it to 550 (just owner bin and group bin can access it), but I don't know if doing this will make strange things with the apps in WAS, or even make DB2Connect to function incorrectly (db2inst1 is gid=47(db2iadm1) groups=47(db2iadm1),48(db2asgrp)) as well as many default-created users (like db2as, db2fenc1, db2inst1) during DB2Connect installation.
Only root, daemon are in the bin group, so I believe that only these users would actually use it if I change it to 550...
Any other recommendations to restrict this command to other/specific users without disrupting the Websphere Application Server's apps?
I'm kind of newbie in this area, so any help is greatly appreciated.
And thanks for taking your time to read this post
- 12-08-2010 #2
- Join Date
- Apr 2009
- I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
I would say that changing the permissions would be appropriate. You'll find out soon enough if this causes problems for other user applications. At that point you can decide how to approach the problem - there are a number of ways to do that.Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!