db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality
Date Wed, 02 Aug 2006 07:36:14 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12425162 ] 
Mamta A. Satoor commented on DERBY-1330:

Laura, here are my attempts at your questions. 

derby.connection.requireAuthentication is a pre 10.2 property which enables user authentication.
This property will require that a user name and password is supplied at database connection
time. Chances are that in  a multi-user environment, Derby would be run with authentication
enabled (more info can be found in our existing docs in the 
Security->Derby and Security -> Working with user authentication -> Enabling 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 different users once they
are connected to Derby. This part falls under User authorization. More on this can be found
Security->Derby and Security -> User authorization -> Setting user authorization

Prior to Derby 10.2, you could use derby.database.defaultConnectionMode to specify the default
access mode to be noAccess, readOnlyAccess and fullAccess. 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.sqlAuthorization. When you set this property
to true, Derby is said to be running in Derby SQL Standard Authorization mode. So, in short,
property derby.database.sqlAuthorization allows the grant revoke feature. 

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

So, I hope I have not gotten you confused with all the jargons. Existing manuals might be
helpful in clearing out confusion on authentication vs authorization.

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:
>            Reporter: Mamta A. Satoor
>         Assigned To: Mamta A. Satoor
>         Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, AuthorizationModelForDerbySQLStandardAuthorizationV2.html,
DERBY1330javaDocWarningsDiffV9.txt, DERBY1330javaDocWarningsStatV9.txt, Derby1330MinorCleanupV7diff.txt,
Derby1330MinorCleanupV7stat.txt, Derby1330PrivilegeCollectionV2diff.txt, Derby1330PrivilegeCollectionV2stat.txt,
Derby1330PrivilegeCollectionV3diff.txt, Derby1330PrivilegeCollectionV3stat.txt, Derby1330setUUIDinDataDictionaryV10diff.txt,
Derby1330setUUIDinDataDictionaryV10stat.txt, Derby1330setUUIDinDataDictionaryV8diff.txt, Derby1330setUUIDinDataDictionaryV8stat.txt,
Derby1330uuidIndexForPermsSystemTablesV4diff.txt, Derby1330uuidIndexForPermsSystemTablesV4stat.txt,
Derby1330uuidIndexForPermsSystemTablesV5diff.txt, Derby1330uuidIndexForPermsSystemTablesV5stat.txt,
Derby1330uuidIndexForPermsSystemTablesV6diff.txt, Derby1330uuidIndexForPermsSystemTablesV6stat.txt,
Derby1330ViewPrivilegeCollectionV1diff.txt, Derby1330ViewPrivilegeCollectionV1stat.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 order to do that, first we need to collect
the privilege requirements for various database objects and store them in SYS.SYSREQUIREDPERM.
Once we have this 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. The database object access will succeed only if the
user has the necessary privileges.
work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't have any information in it at this point
and hence no runtime privilege checking is getting done at this point.

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


View raw message