The DBA's insist that they need access to the OS-level login "sybase"
in order to perform their tasks.

In fact, they've said that there are specific tasks that they do that
require the use of this OS login rather than having a personal account
with membership in the sybase group.

The only real tasks that I can think of that might be performed only
under the "sybase" OS login are checking the system logs (also doable
under any id with group membership) and installation of new revisions.

I understand that invoking isql under the "sybase" login without a id
and password and becoming "SA" is possible only from the server's
console. Otherwise you have to specify "SA" and the password. Correct?

Thanks in advance!

On Tue, 24 Aug 2004 13:38:17 -0700, Byrocat wrote:

Possibly manipulating database dump files (compressing them, etc) might
need "sybase" user id privileges.

No - I don't think that works either. Certainly not on any machine that
I've used. You can only become SA by specifying the appropriate user id at
login time, or by having an account with "sa_role".

Michael
--
Michael Peppler Data Migrations, Inc.
mpeppler (AT) peppler (DOT) org http://www.peppler.org/
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or
long term contract positions - http://www.peppler.org/resume.html

Michael Peppler <mpeppler (AT) peppler (DOT) org> wrote in
newsan.2004.08.25.12.13.42.553651 (AT) peppler (DOT) org:

It's also good for the DBA's to be able to run 'sar' (or the
equivalent) to address any possible performance related questions.
Sometimes the data needs to be reviewed immediately.

I'm curious why you'd want to _not_ allow the DBA's access at the
OS-level. You should be partnering with them, not antagonising them
with a silly turf-like battle.
--
Pablo Sanchez - Blueoak Database Engineering, Inc
http://www.blueoakdb.com

In my opinion, the only time that the 'sybase' OS account is necessary is in
the starting of the sybase server processes (dataserver , backupserver,
xpserver, etc). My experience is in AIX and HP-UX. NT requirements may be
different. While I utilize the OS account 'sybase' to provide the crontab
entries for my maintenance jobs, that is just a convenience. Everything
else is fluff or ego. I've had similar arguments over the sybase sa user id
vs. a personal id with the sa_role.



When logged in to the OS as sybase and you use isql without a -Uxxxx option,
the software expects an internal user name of sybase to be in the syslogins
table. Until specific permissions are granted to the name sybase, it is no
different than any other initial user id.

"Byrocat" <bdealhoy (AT) sympatico (DOT) ca> wrote

I'm mystified by how many organizations separate UNIX from DBMS roles. In
my division we do both and leave LAN/NT to a separate group. Every one has
their strengths and weaknesses - I'm much stronger with ASE than with
SQL-Remote, ASA, Oracle or Solaris. But we all have enough knowledge to
cover the bases (and time slots) for production issues. This way we also
understand a bigger picture of the issues.

I remember an Oracle DBA II class where the instructor taught a class where
a UNIX admin was sent in order to understand the need for enlarging Oracle
files. Afterwards the student understood it ... but still wouldn't give the
permission to the Oracle admins! Sometimes the problems aren't with the
organizational structure.


"Pablo Sanchez" <honeypot (AT) blueoakdb (DOT) com> wrote

bdealhoy (AT) sympatico (DOT) ca (Byrocat) wrote in message news:<b47d3acf.0408241238.7514a809 (AT) posting (DOT) google.com>...
You've identified some reasons why DBA's would need access to sybase
account which essentially answered your question.

bdealhoy (AT) sympatico (DOT) ca (Byrocat) wrote in message news:<b47d3acf.0408241238.7514a809 (AT) posting (DOT) google.com>...
Assuming we are talking ASE here.

Not sure where you are getting that last from, unless perhaps you are
using the network-based security "unified login" type of features -
but even then, the console really has nothing to do with it.

The normal behavior is that if you don't specify a login name for isql
with -U, it defaults to $LOGIN or $USER (forget which offhand). There
is no such default for password (though there is an existing feature
request) It is possible to set up an account with a null password, but
you could login using it from anywhere. It is also possible to alias
"isql" to "isql -Usa" in user's shell.

-bret

The ability of isql to hook in as "SA" from the operator's console may
be just a foggy memory. Kindly ignore it.

HOWEVER, we are in a shop that runs all levels of metal (IBM
mainframes, AIX/Unix/Linus/HP-UX, windows servers, network
applicaitons), and the stated policy from the security mavins is that
ALL powerful ids (operating system as well as within the databases)
are to be locked down and available only on a firecall basis (existing
problem log or change/promotion request). We have an online
applicaiton that logs and tracks the requests, and reports wind up on
managers' desks first thing in the morning for sign-off.

The DB2 guys use the firecall applicaiton, the Informix guys do too,
the Windows server guys, and the Oracle guys as well. The only ones
who don't and are squawking are the Sybase guys.

I'm in the process of documenting what can and cannot be done so our
CISO can render an intelligent decision.

Right now, it looks like the recommendation is "do it like everyone
else here."

Pablo Sanchez <honeypot (AT) blueoakdb (DOT) com> wrote


What is 'SAR"? I'll check in teh online help but could you give an
illustration.

I've answered your question about why in my previous post -- stated
security policy is that all powerful OS and database ids are secured
and tracked. If they're needed and for a valid reason, it takes five
minutes total time log into the applicaiton, request the password, and
then to return it later.

bdealhoy (AT) sympatico (DOT) ca (Byrocat) wrote in
news:b47d3acf.0408261213.e74fbb3 (AT) posting (DOT) google.com:

'man sar'

What's the name of the company you work for?
--
Pablo Sanchez - Blueoak Database Engineering, Inc
http://www.blueoakdb.com