1. A function is nothing implemented as service program. Like any service
program authority can be managed by using CL Commands, but also by using one
of the SQL commands GRANT and REVOKE.
System i Navigator has wizards for managing the preferences for any
database object.
2. Who will be the owner and who can access an database object depends on
the naming convention used when creating the database object.
When using the system naming convention, the owner will be the creator or
the group profile and *PUBLIC has *EXLUDE authority
When using the SQL naming convention, the owner will be either the creator
or the user profile with the same name as the schema in which the function
will be created.
SYSPROCS, SYSFUNCS (and all other SYS* files) are views that cannot be
modified manually so removing authority will not prevent someone from
dropping and recreating any database object.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Michael Naughton
Gesendet: Friday, 14.9 2012 18:14
An: Midrange Systems Technical Discussion
Betreff: Re: Security for SQL functions
Again, I understand that, but it still seems like a different situation to
me. If I have PGMA and PGMB, I can grant GROUPA authority to PGMA and GROUPB
authority to PGMB. But if I have FUNCA and FUNCB, I don't see any way to
grant GROUPA authority to DROP FUNCA but not FUNCB, and GROUPB the
opposite. It seems to me that if I can DROP one function, I can DROP all
functions, so to prevent me from dropping FUNCA I'd have to be prevented
from dropping any function.
Maybe that's okay with the OP, but it's not quite the same as "each function
is an object" .....
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> writes:
Hi, Michael:
Take a look at:
DSPOBJAUT QSYS2/SYSROUTINE *FILE
Then you could use EDTOBJAUT or GRTOBJAUT or RVKOBJAUT to alter the
*PUBLIC authority and only grant *CHANGE authority to those whom you
want to be able to do those operations on this table. You may want to
create a group profile or authorization list to control who is able to
update this table.
(OS/400 object security applies to all objects, including database
tables.)
Hope that helps,
Mark S. Waterbury
Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA 01376
413-676-3144
Internal: x 444
mnaughton@xxxxxxxxxxxx
****************************************
NOTICE: This e-mail and any files transmitted with it are confidential and
solely for the use of the intended recipient. If you are not the intended
recipient or the person responsible for delivering to the intended
recipient, be advised that any use is strictly prohibited. If you have
received this e-mail in error, please notify us immediately by replying to
it and then delete it from your computer.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
