Hi,
Dr. Dweeb. wrote:
> Try comp.database.rdb or the oraclerdb mailing list at jcc.com
> or the Oracle Enhancement Request system - the Rdb
> engineers definitely read one or more of these.
I've just gone back through my archives and counted over 40 posts relating
to this topic. Mostly in the Rdb Listserver. The earliest date I could
find
was July 10, 2000 and possibly the most relevant attached below (Feb 2,
2003) containing the bollocks Oracle ERS reply.
We all know that this is a useful piece of functionality that poses NO
security risks, and would be very easy to implement. But sadly we also
know
that once one of these engineering Oligarchs decide they don't want to do
something and that they'd rather go off and implement that "snooze-button
on
a smoke-alarm" project that "real customers" have been asking for, then
there's not much that the likes of me can do about it :-(
But 40 replies is no where near enough for me! I'm happy to be proved
wrong
on this and discuss it for as long as you, or anybody else, would like.
"There is *NO* valid reason why SQL> SET SESSION AUTHORIZATION PERSONA /
CURRENT / NATURAL / :ws_integer can not be implemented in Rdb" - discuss.
Please Note: For those of you that don't know Rdb, we *already have* SQL>
SET SESSION AUTHORIZATION 'USER ''fred'' USING ''password'''; The
functionality for Session Level authorization already exists! What we need
is the ability to not pass passwords in the clear but simply authenticate
the session user switch on a Persona basis.
Take a look at DEMO_TIP.COB, DEMO_TIP_SQL.SQLMOD and BUILD_TIP_DEMO.COM.
These User Action Routines are SCREAMING out for the ability to changes
Session Authorization in Rdb every time we get a different user in a
client/server environment. Maybe FRED has write access to the Departments
table but JACK does not and he doesn't have the DB_WRITE identifier.
Please
let Rdb fully exploit this lovely VMS functionality!!!
Things like sys$check_access and sys$getqui (jbc$_search_as_username?) are
no longer a necessity. Please wake up to it.
Regards Richard Maher
PS. How many of you ACMS users out there have a TPU Re****t/File Browse
function implemented in a DCL Server? tick-tick. . . tick-tick. .
..tick-tick. . .
----- Original Message -----
From: Richard's Hotmail
Sent: Sunday, February 02, 2003 1:27 PM
Subject: I'm begging ya (Was: Oracle's lovely Enhancement Request System
(again)
Hi Ian,
For those who didn't see the ERS request, I decided to formally request an
enhancement to Rdb that would allow the SQL syntax SET SESSION
AUTHORIZATION
to cater for the specification of a VMS Persona Id rather than a Username
and Password. This was the response from Oracle:-
*** ISMITH 01/14/03 10:07 am RESPONSE ***
It is unlikely that we will implement such a change to SET SESSION
AUTHORIZATION. We believe it opens a security hole, since an unprivilege
user could use this statement to revert to the natural persona and then
proceed to inherit the abilities of the server owner.
..
Richard this is the same reason we rejected you suggestion to sup****t SET
SESSION AUTHORIZATION DEFAULT.
*** End Response
When you say "an unprivilege user could use this statement to revert to
the
natural persona and then proceed to inherit the abilities of the server
owner." Are you alluding to some PP design issues with SQL/Services where
the server owner is required to have some elevated privileges? If so then
please feel free to restrict the environments that the PERSONA :ws_integer
syntax would be legal in to SQL Module Language and Pre-Processors. I
agree
there is little scope for it in Interactive and Dynamic SQL.
But on second thoughts could you please explain how an unprivileged user
gets to specify the natural persona? I assume you mean that they will
somehow specify iss$c_id_natural, but do you have a specific server in
mind?
In my case, it is my server code and user supplied application code that
controls which personae can be assumed and when. Do you envisage the user
being prompted for a persona Id?
But more im****tantly what, exactly, would be wrong with reverting to the
natural persona and inheriting the abilities of the server owner? I have
gone to great lengths to ensure that my server software requires no (I
repeat *NO*) special privileges other than what the application may
require
to perform its specific functions. Surely this is the quintessential VMS
security policy (Start with no privs and only enable them when you need
them.) Are you aware that, on Alpha at least (and once again please feel
free to restrict this functionality to Alpha), an access mode can be
associated with a persona that would prevent a USER mode call to
$persona_assume being able to grab hold of an EXEC mode persona? If you
don't want a persona to be assumed from User mode then protect it in an
inner mode.
But leaving these cogent arguments to one side for the moment let's keep
it
simple and cut to the chase. At this particular point in time and with no
change to Rdb am I able to do the following:-
$persona_assume fred's_persona
attach 'file db';
go crazy
disconnect
$persona_assume iss$c_id_natural
attach 'file db';
go even crazier
disconnect
Do you not agree (as I have said *many* times before over previous
*years*)
that all the absence of this functionality is doing is succeeding in
slowing
the application down. it is not *preventing* anything except performance!
And one final note. How do you feel about passing a user's username and
password to application code in the clear? Obviously you don't have a
problem with it but I for one see this as far more of a security issue
then
being able to swap to authorized personae. But more on that in a minute.
I (and every client/server application out there) really want this
functionality. Please can we send it up for review/appeal one more time?
Isn't there anyone else out there with even ACMS servers that would like
to
hit the database as the *real* user and not a generic username? Granting
and
Revoking rights and ACLs on a user by user basis! How 'bout that eh?
Regards Richard Maher.
PS. Does everyone else in the U.K. know that the Oracle sup****t ...947
number no longer exists? It is now impossible to pick up the phone and
talk
to anyone who knows how to spell Rdb. It's Metalink or nothing :-( I
shudder
to think what you get for bronze service.
Oh and it was a nice touch you writing here to tell me to raise a sup****t
call there to find out what you wrote over there.
----- Original Message -----
From: Ian Smith
Sent: Tuesday, January 14, 2003 6:55 PM
Subject: Re: Oracle's lovely Enhancement Request System (again)
Your request was rejected as being a security hole.
Sorry, please contact Oracle sup****t and complain about the ERS system.
They can also read you the response.
Ian
Richard's Hotmail wrote:
Hi, Before I lose my rag completely with ERS can anyone tell me how I can
find out *why* my suggestion was rejected? This systems semingly arbitrary
truncation of my request left the underlying suggestion barely inteligible
(admittedly didn't start off with much either) but this is one of those
big
gains for little effort stories. I just can't understand it! The ERS
reference is 2747493. Regards Richard (I will bang on about this) Maher.
--
Ian Smith Read the Technical Corner column
Oracle Rdb Engineering Group in the Rdb Web Journal
(Standard disclaimer: The statements and opinions expressed here are my
own
and do not necessarily represent those of Oracle Cor****ation)
"Dr. Dweeb" <NOSPAM_5msg0h202@[EMAIL PROTECTED]
> wrote in message
news:42b334d6$0$67263$157c6196@[EMAIL PROTECTED]
> Try comp.database.rdb or the oraclerdb mailing list at jcc.com or the
Oracle
> Enhancement Request system - the Rdb engineers definitely read one or
more
> of these.
>
> Dr. Dweeb.
>
> Richard Maher wrote:
> > Hello,
> >
> > I know I've been going on about this enhancement request for quite
> > some years now, but if there is any justice in the world then it has
> > to be coming up in the next version(s) of Rdb. With that in mind,
> > please let me advise that you may wish to provide a API call
> > (with/without the SQL syntax) to switch session authorization on a
> > persona basis. Why? Because it could be quite valid to switch
> > authorization to an EXEC mode person, but without the process going
> > into inner mode how can you tell if this was legitimate?
> >
> > You *could* have SQL> set session authorization 'persona current';
> >
> > Rdb would then do a $persona_query on the current *zero* persona.
> > (Who cares what mode it is? It's current so it must be ok)
> >
> > Anyway, If by the odd chance, you are implementing this and you plan
> > on banning non-user-mode personae then please think again.
> >
> > Cheers Richard Maher
>
>
|
