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-1057) documentation to address Grant/Revoke (Derby-464)
Date Thu, 10 Aug 2006 04:32:18 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12427097 ] 
            
Mamta A. Satoor commented on DERBY-1057:
----------------------------------------

Laura, I have some feedback on the doc changes.  Also, Deepa recently added a warning as part
of DERBY-1582. We probably should document it wherever we document other warnings.


Comments on Reference Guide

SYSCOLPERMS
1)The 2nd line should say "All of the permissions for one(GRANTEE, TABLEID, TYPE, GRANTOR)"
2)TABLEID description says "The name of the table...". It's not the name, it is the "unique
identifier for the table..."

SYSTABLEPERMS
1)The 2nd line should say "All of the permissions for one (GRANTEE, TABLEID, GRANTOR)"
2)TABLEID description says "The name of the table...". It's not the name, it is the "unique
identifier for the table..."

GRANT statement page
1)Under "Syntax for tables", the "TABLE" keyword should be optional. The syntax should be
GRANT privilege-type ON [TABLE] { table-Name | view-Name } TO grantees
2)Also, the syntax for grantees is shown as
grantees
{
	authorization ID | PUBLIC
}
With this syntax, one can only specify one id at a time. That is not correct. The syntax should
look like following
grantees
	{authorization ID | PUBLIC} [,{authorization ID | PUBLIC}]*
3)For the syntax for privilege-type, ALL PRIVILEGES is missing. This has been correctly included
in the REVOKE statement page.

REVOKE statement page
1)Under "Syntax for tables", the "TABLE" keyword should be optional. The syntax should be
	REVOKE privilege-type ON [TABLE] { table-Name | view-Name } FROM grantees
2)Also, the syntax for grantees is shown as 
grantees
{
	authorization ID | PUBLIC
}
With this syntax, one can only specify one id at a time. That is not correct. The syntax should
look like following
grantees
	{authorization ID | PUBLIC} [,{authorization ID | PUBLIC}]*
3)Following paragraph sounds confusing and incorrect to me
  "You must use the RESTRICT clause on REVOKE statements for routines. The RESTRICT clause
specifies that the EXECUTE privilege cannot be revoked if the specified routine is used in
a view, trigger, or constraint, or if the loss of the EXECUTE privilege would cause the definer
of the view, trigger, or constraint to no longer be able to execute the specified routine."
The correct information is in the functional spec attached to DERBY-464 and it is as follows
  "RESTRICT is mandatory with routine revoke statements. That means that execute permission
on a function may not be revoked if that function is used in a view, trigger, or constraint,
and permission is being revoked from the owner of the view, trigger, or constraint. "
4)In the paragaraph for explanation of REFERENCES, we currently have following
  "If a column list is specified with the REFERENCES privilege, the permission is valid on
only the foreign key reference to the specified columns."
It should be something like following (feel free to reword it)
  "If a column list is specified with the REFERENCES privilege, the permission is revoked
on only the foreign key reference to the specified columns."
Same thing applies to the explanation of SELECT and UPDATE.
5)On both grant and revoke pages, when we talk about a specific authorization ID, we should
use the same case for all the references to that user. We talk about authorization ID harry
as "harry" and "Harry". I see this on "Grant and revoke user authorizations" page also in
Developers Guide.

Comments on Developers Guide
User authorizations
1)In the 2nd paragraph, we start with connection authorization and grant authorization. But
on the 2nd line, I think we are referencing grant authorization as SQL authorization. Might
be confusing to the users.
2)Typo on line "Tip: It is possible to configure a database so that the database cannot be
accesses "
accessess should be accessed
Also, that sentence sounds little confusing to me. I think it needs little rephrasing. My
suggestion (feel free to change it)
  "Tip: It is possible to configure a database so that the database cannot be accessed  or
changed. This can be done using the derby.database.defaultConnectionMode property. If you
set this property to noAccess or readOnlyAccess, be sure to allow at least one user read-write
access."
3)2nd bullet item under "How user authorization properties work together" says that "No one
but the owner of  an object can drop the object. " Actually, it is the owner and the dbe that
can drop a object. I think Dan had suggested some other name for dba, I can't remember right
now what his suggestion was.
4)3rd bullet item "The access mode specified for the derby.database.sqlAuthorization property
" should read as "The access mode specified for the derby.database.defaultConnectionMode 
property "

Setting the SQL standard authorization mode
1)Minor suggestion. This page has following sentence
  "When you set the derby.database.sqlAuthorization property to TRUE, you cannot set the property
back to FALSE."
The sentence might be little more clearer if we said
  "Once you set the derby.database.sqlAuthorization property to TRUE, you cannot set the property
back to FALSE."


Grant and revoke user authorizations
1)This page has following paragraph
  "Only the object owner has full privileges on the object. No other user has any privileges
on the object until the object owner grants privileges to them. "
Actually, the object owner and the dba has full privileges on the object.
2)The following paragraph does not portray the entire picture of privilege dependency at object
creation time
  "Exception: If you create a view, trigger, or constraint when only the PUBLIC privilege
is active, the object  that you create is dependent on the PUBLIC privilege. If you are subsequently
granted the same user privileges as you have with PUBLIC, the objects that you created remain
dependent on the PUBLIC privilege. If the PUBLIC privilege is later revoked, the objects that
you created when only the PUBLIC privilege was active are dropped. Ensure that you have user
level privileges before you create database objects to avoid this privilege dependency."
Laura, can you please go through my last comment in DERBY-1330 and if it is still unclear,
please let me know.

Comments on Tuning Guide
1)derby.database.sqlAuthorization
Minor suggestion. This page has following sentence
  "When this property is set to TRUE, the property cannot be set back to FALSE."
The sentence might be little more clearer if we said
  "Once this property is set to TRUE, the property cannot be set back to FALSE."

Thanks for working on this.

> documentation to address Grant/Revoke (Derby-464)
> -------------------------------------------------
>
>                 Key: DERBY-1057
>                 URL: http://issues.apache.org/jira/browse/DERBY-1057
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Documentation
>    Affects Versions: 10.0.2.0
>            Reporter: Eric Radzinski
>         Assigned To: Laura Stewart
>             Fix For: 10.2.0.0
>
>         Attachments: derby1057_devguide.diff, derby1057_devguide3.diff, derby1057_devguide_html.zip,
derby1057_devguide_html3.zip, derby1057_ref.diff, derby1057_ref3.diff, derby1057_ref_html.zip,
derby1057_tuning3.diff, derby1057_tuning_html.zip, derby1058_ref_html3.zip, devguide_html2.zip,
ref_html2.zip
>
>


-- 
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

        

Mime
View raw message