Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <29571293.1154504174792.JavaMail.jira@brutus>
Date: Wed, 2 Aug 2006 00:36:14 -0700 (PDT)
From: "Mamta A. Satoor (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1330) Provide runtime privilege checking
 for grant/revoke functionality
In-Reply-To: <14984243.1147927445981.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

    [ http://issues.apache.org/jira/browse/DERBY-1330?page=3Dcomments#actio=
n_12425162 ]=20
           =20
Mamta A. Satoor commented on DERBY-1330:
----------------------------------------

Laura, here are my attempts at your questions.=20

derby.connection.requireAuthentication is a pre 10.2 property which enables=
 user authentication. This property will require that a user name and passw=
ord is supplied at database connection time. Chances are that in  a multi-u=
ser environment, Derby would be run with authentication enabled (more info =
can be found in our existing docs in the=20
Security->Derby and Security -> Working with user authentication -> Enablin=
g user authentication section)

derby.connection.requireAuthentication will ensures that a user with valid =
user name and password will be allowed to connect to Derby. A multi-user
environment might also want to control what actions are allowed by differen=
t users once they are connected to Derby. This part falls under User author=
ization. More on this can be found under
Security->Derby and Security -> User authorization -> Setting user authoriz=
ation

Prior to Derby 10.2, you could use derby.database.defaultConnectionMode to =
specify the default access mode to be noAccess, readOnlyAccess and fullAcce=
ss. There was no support for Grant/Revoke pre 10.2.

With Derby 10.2, we are introducing grant revoke which is another scheme of=
 user authorization and it is enabled by the property derby.database.sqlAut=
horization. When you set this property to true, Derby is said to be running=
 in Derby SQL Standard Authorization mode. So, in short, property derby.dat=
abase.sqlAuthorization allows the grant revoke feature.=20

There has been some talk about not requiring property property derby.databa=
se.sqlAuthorization and enabling grant revoke when user attempts to use gra=
nt/revoke sql statements for the first time. Someone more knowledgable abou=
t that discussion might want to add their comments here.

So, I hope I have not gotten you confused with all the jargons. Existing ma=
nuals might be helpful in clearing out confusion on authentication vs autho=
rization.

If you have any further questions, feel free to post them,

> Provide runtime privilege checking for grant/revoke functionality
> -----------------------------------------------------------------
>
>                 Key: DERBY-1330
>                 URL: http://issues.apache.org/jira/browse/DERBY-1330
>             Project: Derby
>          Issue Type: Sub-task
>          Components: SQL
>    Affects Versions: 10.2.0.0
>            Reporter: Mamta A. Satoor
>         Assigned To: Mamta A. Satoor
>         Attachments: AuthorizationModelForDerbySQLStandardAuthorization.h=
tml, AuthorizationModelForDerbySQLStandardAuthorizationV2.html, DERBY1330ja=
vaDocWarningsDiffV9.txt, DERBY1330javaDocWarningsStatV9.txt, Derby1330Minor=
CleanupV7diff.txt, Derby1330MinorCleanupV7stat.txt, Derby1330PrivilegeColle=
ctionV2diff.txt, Derby1330PrivilegeCollectionV2stat.txt, Derby1330Privilege=
CollectionV3diff.txt, Derby1330PrivilegeCollectionV3stat.txt, Derby1330setU=
UIDinDataDictionaryV10diff.txt, Derby1330setUUIDinDataDictionaryV10stat.txt=
, Derby1330setUUIDinDataDictionaryV8diff.txt, Derby1330setUUIDinDataDiction=
aryV8stat.txt, Derby1330uuidIndexForPermsSystemTablesV4diff.txt, Derby1330u=
uidIndexForPermsSystemTablesV4stat.txt, Derby1330uuidIndexForPermsSystemTab=
lesV5diff.txt, Derby1330uuidIndexForPermsSystemTablesV5stat.txt, Derby1330u=
uidIndexForPermsSystemTablesV6diff.txt, Derby1330uuidIndexForPermsSystemTab=
lesV6stat.txt, Derby1330ViewPrivilegeCollectionV1diff.txt, Derby1330ViewPri=
vilegeCollectionV1stat.txt
>
>
> Additional work needs to be done for grant/revoke to make sure that only =
users with required privileges can access various database objects. In orde=
r to do that, first we need to collect the privilege requirements for vario=
us database objects and store them in SYS.SYSREQUIREDPERM. Once we have thi=
s information then when a user tries to access an object, the required SYS.=
SYSREQUIREDPERM privileges for the object will be checked against the user =
privileges in SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS. T=
he database object access will succeed only if the user has the necessary p=
rivileges.
> SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already po=
pulated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't ha=
ve any information in it at this point and hence no runtime privilege check=
ing is getting done at this point.

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira