Home > Archive > SQL Anywhere Feedback > August 2005 > Allow for different owner of MobiLink ml_* objects









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Allow for different owner of MobiLink ml_* objects
Breck Carter [TeamSybase]

2005-08-15, 7:23 am

Please allow for the MobiLink ml_* system objects to be owned by a
different user than the one used to connect to the consolidated
database. In some environments (e.g., a typical Oracle shop), a vast
and complex hierarchy of user and owner names is enforced by the DBAs,
along with other restrictive rules.

Consider the following scenario:

- ml_* objects must be owned by user X
- dbmlsrv9.exe must connect as user Y
- the creation of synonyms is not allowed

Perhaps a new dbmlsrv9 option to "explicitly qualify references to
ml_* objects with user X" would help here.

Breck

PS For those of you having a deja moment, a *similar* but different
request was posted on June 7, 2004; that issue had a workaround, and
in that shop synonyms were allowed.

--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com
Graham Hurst

2005-08-25, 9:23 am

I assume this scenario would be because the DBA's don't want Y to have
object creation privileges. Since you only need to create the ml_*
objects once per database, couldn't Y be given such privileges temporarily?

Do you think this need is at all common? Other than your earlier post,
we haven't heard about it before...

Cheers,

Graham

Breck Carter [TeamSybase] wrote:

> Please allow for the MobiLink ml_* system objects to be owned by a
> different user than the one used to connect to the consolidated
> database. In some environments (e.g., a typical Oracle shop), a vast
> and complex hierarchy of user and owner names is enforced by the DBAs,
> along with other restrictive rules.
>
> Consider the following scenario:
>
> - ml_* objects must be owned by user X
> - dbmlsrv9.exe must connect as user Y
> - the creation of synonyms is not allowed
>
> Perhaps a new dbmlsrv9 option to "explicitly qualify references to
> ml_* objects with user X" would help here.
>
> Breck
>
> PS For those of you having a deja moment, a *similar* but different
> request was posted on June 7, 2004; that issue had a workaround, and
> in that shop synonyms were allowed.
>
> --
> SQL Anywhere Studio 9 Developer's Guide
> Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
> bcarter@risingroad.com
> RisingRoad SQL Anywhere and MobiLink Professional Services
> www.risingroad.com

Breck Carter [TeamSybase]

2005-08-25, 11:23 am

On 25 Aug 2005 07:14:49 -0700, Graham Hurst
< spam_guard_hurst@ian
ywhere.com> wrote:

>I assume this scenario would be because the DBA's don't want Y to have
>object creation privileges. Since you only need to create the ml_*
>objects once per database, couldn't Y be given such privileges temporarily?


Sadly, no. The whole "point" of the rule is that the owner and the
connecting user ids must be different. Don't ask why, I have
absolutely no idea.

>Do you think this need is at all common? Other than your earlier post,
>we haven't heard about it before...


Perhaps it is a kind of DBA Flu that is going around :)

I suppose the last-resort workaround is to edit syncora.sql, something
I don't like to do since that just introduces one more maintenance
pain point.

Breck

[color=darkred]
>
>Cheers,
>
>Graham
>
>Breck Carter [TeamSybase] wrote:
>

--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com
Sponsored Links





Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive | Programming forum archive

Copyright 2008 droptable.com