[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::sql_services

Title:SQL/Services Forum
Notice:kits(3) ft info(7) QAR access (8) SPR access (10)
Moderator:SQLSRV::MAVRIS
Created:Thu Oct 13 1988
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2214
Total number of notes:8586

2173.0. "Database service priv problem with DO" by chsr38.ch.oracle.com::ROHR (The Packers did it!) Thu Mar 20 1997 10:05

    AXP Rdb 7.0.0.1 (pre) Distributed Option 7.0 SQS V7.0
    
    I can access my distributed Option db with the SQL Services sample by
    using 
    
    attach 'filename /type=dbi/dbname=gbs_do';
    
    I can't get this to run as database service with authorization set to
    connect user name.
    
    However, doing the attach on the physical database in a database
    service is ok. 
    
    What am I doing wrong?
    And does s.o. know how to find this SQL Services sample on NT (not
    having one...)
    
    %SQLSRV-I-EXECSQLERRSTM, SQL statement: attach 'filename
    /type=dbi/dbname=w2:[pm
    slogs.log73552]gbs_do'
    %SQLSRV-I-EXECSQLERRSTS, SQLCODE: -1028, SQLERRD array: [0]=0, [1]=0,
    [2]=0
    %SQLSRV-I-EXECSQLERRMSG, SQL error message:
    %RDB-E-NO_PRIV, privilege denied by database facility
    -DBI-F-PRIVVIO, Privilege violation encountered for current DBI
    database user SQLSRV$DEFLT 
    
    It doesn't seem right that a database service gets the priv violation
    and not the universal service when I supply the attach string.
    SQLSRV$DEFLT is alos the owner of the universal service.
    
    Thanks,
    Regina
T.RTitleUserPersonal
Name		DateLines
2173.1M5::JHAYTERThu Mar 20 1997 11:2711
Regina,

The service owner has to have at least select priv on the DB, but not the
tables.  This is documented, see page 2-39 in the server config guide.

You will see the DB being attached to by the service owner.  The users
DB privs will be used for further access to the DB.  At least that is the
way I understand it, but I certainly don't understand the black magic they
pull to attach as "service owner", then become "user".

Jerry
2173.2chsr38.ch.oracle.com::ROHRThe Packers did it!Thu Mar 20 1997 12:075
    Right. Documented. Why did I stop on 2-37? Too many calls...
    Will try,
    Thanks,
    
    PS: If s.o. knows how to locate SQL Services on NT?
2173.3Hiding under a cabbage leaf? :)BOUVS::OAKEYI'll take Clueless for $500, AlexThu Mar 20 1997 12:3610
>>     <<< Note 2173.2 by chsr38.ch.oracle.com::ROHR "The Packers did it!" >>>

>>    PS: If s.o. knows how to locate SQL Services on NT?

What part of SQL/Services on NT are you looking for?  How to install or 
where would it be if it was installed?

It's on the client CD.  (As well, I believe the clients are also on the 
full kits.)
2173.4Doesn't work at all on Unix, may or may not work on VMSORASQS::OXBURYOracle Corporation, Rdb Desktop Group|DTN 381-2704Thu Mar 20 1997 13:0613
    I've not tried this on VMS, but from what I remember from the days when
    we did the Unix port, DBI doesn't support the internal Rdb hacks that
    SQL/Services uses to implement a database service with database
    authorization by connect user name. I don't have time to go into
    details, but as of Rdb 6.1/7.0, it all works by the executor running
    under the dbsmgr user name on Unix or having the RDB$TRUSTED_USER
    identifier on VMS, thus allowing SQL/Services to hand a user name with
    no password to the Rdb exec, and it trusting that information, because
    it knows its operating in a trusted environment. As far as I know, DBI
    doesn't have the code that supports that, at least it didn't. On the
    other hand, if it does work on VMS, then great, one less problem!! :-)
    
    Si
2173.5chsr38.ch.oracle.com::ROHRThe Packers did it!Fri Mar 21 1997 05:306
    In fact, I HAD GIVEN  SELECT to the service owner, and it still
    wouldn't work. I can't test this today, but will have a look into the
    suggestions in .4.
    Thanks,
    Regina
2173.6chsr38.ch.oracle.com::ROHRThe Packers did it!Fri Mar 21 1997 05:3912
    .3:  On my Windows 95 PC I have, in the program list, something called
    SQL Services, that contains an IVP, and a sample. I reinstalled SQLservices
    on another W95 client and I can't find this SQl Services Program, I
    checked on the disk if I could identify an exe to call this sample
    (which asks for node, protocol, username, password, service). 
    
    So where does this come from, if not from a Sql services installation
    on a PC? Or is this a leftover from some of my FT installs?
    
    Thanks,
    Regina
2173.7M5::JHAYTERFri Mar 21 1997 10:049
>    .3:  On my Windows 95 PC I have, in the program list, something called
>    SQL Services, that contains an IVP, and a sample. I reinstalled SQLservices
>    on another W95 client and I can't find this SQl Services Program, I

That came from installing the development piece of SQLservices.
From orainstall, expand out what you have for oracle sql services.  you
will see runtime and development.
2173.8Rdb-F-UNS_RCIchsr38.ch.oracle.com::ROHRThe Packers did it!Mon Mar 24 1997 04:5012
    I granted Rdb$trusted_user to the service - no change.
    
    I granted SELECT to PUBLIC while attached to the logical database. I
    still can't start the executor, but the error message on the client
    changed: 
    
    Rdb-F-UNS_RCI,RCI call rdb_set_authorization is not supported by
    Database Integrator.
    
    I guess I will ask in the DBI notesfile.
    /Regina
2173.9DON'T grant that Ident to any accnts/feature not supported by DBIORASQS::OXBURYOracle Corporation, Rdb Desktop Group|DTN 381-2704Mon Mar 24 1997 09:4514
    The previous note I entered was an attempt to briefly describe the
    INTERNALS that SQL/Services uses to handle database services with
    database authorization by connect user, so as to explain that as far as
    I know, DBI, does NOT support the interface that Rdb provides to
    SQL/Services to support database services with database authorization
    by connect user. In this respect, RDB$TRUSTED_USER is an identifier
    that SQL/Services dynamically and automatically grants to executor
    PROCESSES for database services with database authorization by connect
    user; its not something that customers have to deal with. DO NOT grant
    this identify to any account; doing so will allow that account to do
    anything with any database on your system, given the knowledge of how
    to do it. 
    
    Si