Kbase 12263: Metaschema tables for database and dictionary security
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
Metaschema tables for database and dictionary security
PROGRAMMING HANDBOOK -- you should look for the "offending" userid in
("NOT userx") in front of the entry in _File._Can-Read (or _Can-Write,
If you are having trouble re-establishing a user's security,
you will need to manipulate the access to the database by
direct modification of the metaschema fields which determine
compile-time security. In particular, end users who are
developing their own ad hoc queries and reports, or end users
generating source code via RESULTS, may need this.
After disallowing the BLANK USERID to access the database, you
can re-establish the blank userid with the procedure below,
provided you have created at least ONE other user, whose
permissions include being able to write to the _file table
(_file._can-write).
for each _file:
display _file-name format "x(10)"
_can-read format "x(20)"
_can-write format "X(10)"
_can-create format "X(10)"
_can-delete format "X(10)"
.
assign _can-read = "*"
_can-write = "*"
_can-create = "*"
_can-delete = "*".
end.
This sets all of the permissions back to the default -- all users
have all access privileges. Or you can use UPDATE to modify the
existing privilege settings instead of ASSIGN.
RESULTS security is subject to what is set in the dictionary
metaschema. The field names are documented in section 15.4.6 of the
PROGRAMMING HANDBOOK -- you should look for the "offending" userid in
the _Can-Read field of the _File table where _File-name is the table
in question. Manually or in a program, you need to remove the "!"
("NOT userx") in front of the entry in _File._Can-Read (or _Can-Write,
depending on what you are doing).
See also $DLC/prodict/user/userblnk.p.
Progress Software Technical Support Note # 12263