We have a number of production environments and are looking at securing the Sybase servers, including all OS-level logon IDs such as "sybase". The operational DBAs insist that they need "sybase" on a daily basis and that having the logon ID available as a firecall is unworkable.
As far as I can tell, the OS-level logon ID "sybase" is only used for the following tasks:
- Installation and update/upgrade of the Sybase softare
- Starting of the database and backup server software after a shutdown (OS or Sybase)
- Looking at Sybase's log files (really reaching for this one...)
Are there any other tasks that need the OS-level logon ID to perform as opposed to a generic user account that's a member of the OS-level group "sybase"?
Requires Free Membership to View
In my opinion it makes sense for DBAs to have local access to Sybase account. Sybase is almost always created as a local account on the server (as opposed to a NIS account). I believe DBAs need to have access to Sybase login for a variety of reasons that you mentioned plus maintaining the cronjobs for Sybase (as opposed to running Sybase crons as root etc.).
To remedy this problem, create a NIS account for each DBA under "his/her login name" as opposed to Sybase. Then your Unix SA can easily set up a "sudo" facility to allow the DBA to access Sybase without knowing Sybase login password. This should work generally. In the example below, I have a NIS account called 'micht' which allows me access to the host hp3, which has Sybase data server. I log in as "micht" and then "sudo" to Sybase without knowing Sybase login password.
login as: micht micht@hp3's password: Last successful login for micht: Thu Aug 26 12:04:06 GMT0BST 2004 Last unsuccessful login for micht: Thu Aug 26 20:09:14 GMT0BST 2004 Last login: Thu Aug 26 12:04:29 2004 from 172.16.113.196 [micht@hp3:/home/micht]$ sudo su - sybase [sybase@hp3:/opt/sybase]$
This was first published in August 2004
Join the conversationComment
Share
Comments
Results
Contribute to the conversation