I think that this conversation is getting way off of the topic. No
more personal comments and asides please. Stick to the topic -- what
is the OS login "sybase" used for.

Byrocat wrote:
Starting/Stopping applications owned by the 'sybase' account, eg,
dataserver, backupserver, monserver, histserver, repserver, ltm's, etc.
Also 'kill'ing those applications that won't shutdown gracefully.

Modifying/managing sybase-owned files, eg, manual changes to configuration
files and the interfaces file(s), moving/editing/pruning errorlog files,
removing .mrg/.krg files when an application (eg, dataserver, monserver)
did not shutdown gracefully, accessing/cleaning up shared memory segments
(again, when an application did not shutdown gracefully),
moving/deleting/compressing dump files. Basically dealing with any
directory/file issues where the directory/files are owned by 'sybase'.

Adding/editing/modifying UNIX shell scripts used to manage various sybase
applications, eg, update stats, dumping databases and transaction logs,
running DBA-owned batch jobs, etc.

Accessing/modifying the sybase account's cron/at jobs as well as mail
account/folder(s).

There are most likely others (see other posts).

Yeah, in each of the above cases you could come up with special shell
scripts to provide the same capability ... or provide for
ask-for-it-and-be-granted-one-time-access procedures ... etc, etc, etc. I
find that, typically, the more of this type stuff thrown in the middle ...
the longer it takes to get anything done ... and the greater the chance
that a DBA will go looking for a job with another company where they don't
have to jump through so many hoops in order to do their daily jobs.

I guess my question to you (or your security-minded folks) ... why not
allow the DBA's access to the 'sybase' UNIX account? If it's a question of
how much 'damage' they could do to your database(s) ... they can do a heck
of a lot of damage with just the 'sa' password ... then again, if there is
this type of concern then the security folks should get rid of the DBA's
and do the DBA job themselves, eh? ;-)

--
Mark A. Parsons

Iron Horse, Inc.
iron_horse (AT) NOSPAM (DOT) compuserve.com

"Mark A. Parsons" <iron_horse (AT) NOSPAM (DOT) compuserve.com> wrote


We had to do a Sarbanes-Oxley review of applications' logical access
controls and this is one of the many issues that came out. The SA
account is already locked and has been since we took over LAC several
years ago.

We already have firecall and similar controlled ids that are available
to do the serious stuff within the database when it's called for or
justified.

I get the feeling (and you do touch on it as well), that the DBA's
(and I was one too until I took on this role) feel that this will be
an impediment to their being able to do what they want, when they want
and how they want.

The mainframes as well as the mid-range OS systems are already
controlled, and so is the mainframe databases for powerful ids at the
database and OS level. What's intended is that the Sybase OS ids
become part of that system, which has been used for more years than
I've been here.

If you need the id and it can be justified; it's available 7/24 and
immediately. The application that controls the powerful id passwords
sends a report to your manager and the security reviewers for
follow-up. Takes a minute to hook into the applicaiton, enter the
form's contents and receive the password.

Some will call it "Big Brother" and worse. Perhaps. However, I've
been given my employer's logical access standards and told to find out
what doesn't match the standards and what needs to be done to fix it.

Whether or not the changes I'll be recommending go into place is not
my problem. However, I have to make sure that what I recommend does
meet those standards.