Interesting, Object owner does not have authority to object. (new info)
Charles Wilt
logical file to create a duplicate in another library (yes the PF was
already there) user the user profile who owned both the based on PF and
the LF. And I got a message saying that I wasn't authorized to the
object.
Now for some background, the LF was created via the CREATE ENCODED VECTOR
INDEX statement by another user profile. Then I used CHGOBJOWN
CUROWNAUT(*REVOKE) to change the owner of the LF to my application
owners' user profile. This profile is the profile I later used to issue
the CRTDUPOBJ command.
When I display the object authorities for the LF, it does show that the
profile I'm using is the owner. That profile shows an object authority
of USER DEF, the detail shows Opr, Mgt, Exist, Alter, and Ref for the
object authorities and only Execute for the data authorities.
I guess the lack of Read authority for the data is what is causing the
error.
Maybe I shouldn't be using CRTDUPOBJ on this LF since is actually a EVI
but I can use a user profile with *ALLOBJ to CRTDUPOBJ.
Any ideas/comments about what is going on here?
--
Charles Wilt
Miami Luken, Inc.
e-mail: charle...@worldnet.no.spam.att.net
--->remove the no.spam.
Stamey
authority list on it that does not allow the profile you are using to do the
action, that could be your problem. I have been busted by this one. Even
though the user owned it, they couldn't touch it.
--
Chris Stamey
-----------------
M...@Stamey.nu
http://www.Stamey.nu
http://www.Farther.com/VBAnswerNetwork
Network Engineer
Windows NT Administrator
Aspiring AS400 Administrator
VB Developer
ASP and Web Developer
More to come...
-----------------
Charles Wilt wrote in message ...
Tim
he owns
So, even if the owner is excluded, he may grant himself whatever authority
he wants.
Stamey wrote in message ...
Charles Wilt
says...
> Check the CRTAUT (Create Authority) value on the library. If it has an
> authority list on it that does not allow the profile you are using to do the
> action, that could be your problem. I have been busted by this one. Even
> though the user owned it, they couldn't touch it.
>
> --
> Chris Stamey
> -----------------
> M...@Stamey.nu
> http://www.Stamey.nu
> http://www.Farther.com/VBAnswerNetwork
> Network Engineer
> Windows NT Administrator
> Aspiring AS400 Administrator
> VB Developer
> ASP and Web Developer
> More to come...
Nope, that is not the problem. I used the same user profile to create a
few dozen other PF and LF in the that library.
Charles Wilt
scot...@home.com.xyz says...
> The object owner is *ALWAYS* allowed to specify the authority to the objects
> he owns
>
> So, even if the owner is excluded, he may grant himself whatever authority
> he wants.
>
with the user profile that owns them and although I get a message saying
them were changed they in fact do not change.
Also, I tried changing the authorties with my own user profile w/*ALLOBJ
*QSECOFR. And I get the same thing, a message saying they were changed
but in fact the authorities are not changed.
Very weird, it must have something to do with the fact that the object we
are dealing with is a LF created by the system when I created a EVI on a
physical file.
Charles R. Pence
> Ran across something interesting I was trying to use CRTDUPOBJ on a
> logical file to create a duplicate in another library (yes the PF was
> already there) user the user profile who owned both the based on PF and
> the LF. And I got a message saying that I wasn't authorized to the
> object.
>
> Now for some background, the LF was created via the CREATE ENCODED VECTOR
> INDEX statement by another user profile. Then I used CHGOBJOWN
> CUROWNAUT(*REVOKE) to change the owner of the LF to my application
> owners' user profile. This profile is the profile I later used to issue
> the CRTDUPOBJ command.
>
> When I display the object authorities for the LF, it does show that the
> profile I'm using is the owner. That profile shows an object authority
> of USER DEF, the detail shows Opr, Mgt, Exist, Alter, and Ref for the
> object authorities and only Execute for the data authorities.
>
> I guess the lack of Read authority for the data is what is causing the
> error.
>
> Maybe I shouldn't be using CRTDUPOBJ on this LF since is actually a EVI
> but I can use a user profile with *ALLOBJ to CRTDUPOBJ.
>
> Any ideas/comments about what is going on here?
DSPFD on your EVI *FILE object will show the 'Allow' values are all set to No.
As such all attempts to set the data authorities will effect MSGCPF3224; the
authorities will be removed when attempting to set -- review the joblog for the
diagnostic message.This would appear to be a side effect of the use of *READ
(dis)allow value to effect preventing I/O to the EVI *FILE. HTH.
Regards, Chuck
All comments provided "as is" with no warranties of any kind whatsoever.
Charles Wilt
>
> DSPFD on your EVI *FILE object will show the 'Allow' values are all set to No.
> As such all attempts to set the data authorities will effect MSGCPF3224; the
> authorities will be removed when attempting to set -- review the joblog for the
> diagnostic message.This would appear to be a side effect of the use of *READ
> (dis)allow value to effect preventing I/O to the EVI *FILE. HTH.
>
> Regards, Chuck
> All comments provided "as is" with no warranties of any kind whatsoever.
>
>
I see a CPF3234 Data authority ignored for file, message in the joblog.
But I don't see the one you mentioned.
So now we know because no I/O is allowed to the EVI *FILE object the no
one including the owner has *READ ability to the data. Because the owner
doesn't have *READ, he can't use CRTDUPOBJ on the EVI *FILE object.
Now the question is, why can a user with *ALLOBJ authority use CRTDUPOBJ.
Short answer I guess is that even though no I/O is allowed, the *ALLOBJ
does in fact give you *READ authority, thus the CRTDUPOBJ command works.
That being the case, should this CRTDUPOBJ command on a *FILE object
created by the system for an EVI work at all? If it is an accepted
method of creating a duplicate EVI, why can't the user of the object use
it?
guess it is about time to send a message to IBM to find out what is going
on.
Kent Milligan
behavior as LF object created with the SQL CREATE INDEX statement. If
not, then the problem should be reported to IBM service.
--
Kent Milligan, DB2 & Business Intelligence team
AS/400 Partners In Development
km...@us.removethis.ibm.com GO HAWKEYES!!
(opinions stated are not necessarily those of my employer)
Randy Egan
This behavior of not being able to do a CRTDUPOBJ was not contemplated
during the design. Our goal was to disallow anyone from trying to use
an EVI as an access path through which data can flow. EVIs are only for
creation of dynamic bit maps. That fact so noted, CRTDUPOBJ is not the
same as CPYF since it really is an object operation and should have been
allowed. Please make a formal request to IBM, so that we are nudged to
do something about it.
Thanks
Randy Egan, IBM Rochester
Charles Wilt
> The LF object created for EVI's should have the same authority/property
> behavior as LF object created with the SQL CREATE INDEX statement. If
> not, then the problem should be reported to IBM service.
>
>
>
authority of *ALL.
Charles Wilt
says...
> Charles,
>
> This behavior of not being able to do a CRTDUPOBJ was not contemplated
> during the design. Our goal was to disallow anyone from trying to use
> an EVI as an access path through which data can flow. EVIs are only for
> creation of dynamic bit maps. That fact so noted, CRTDUPOBJ is not the
> same as CPYF since it really is an object operation and should have been
> allowed. Please make a formal request to IBM, so that we are nudged to
> do something about it.
>
> Thanks
>
> Randy Egan, IBM Rochester
>
Randy, I've already submitted a problem report (64695,082) I'll post any
response from IBM in the group for others following this thread.
Charles R. Pence
> I see a CPF3234 Data authority ignored for file, message in the joblog.
> But I don't see the one you mentioned.
>
> So now we know because no I/O is allowed to the EVI *FILE object the no
> one including the owner has *READ ability to the data. Because the owner
> doesn't have *READ, he can't use CRTDUPOBJ on the EVI *FILE object.
>
> Now the question is, why can a user with *ALLOBJ authority use CRTDUPOBJ.
> Short answer I guess is that even though no I/O is allowed, the *ALLOBJ
> does in fact give you *READ authority, thus the CRTDUPOBJ command works.
> That being the case, should this CRTDUPOBJ command on a *FILE object
> created by the system for an EVI work at all? If it is an accepted method
> of creating a duplicate EVI, why can't the user of the object use it?
>
> guess it is about time to send a message to IBM to find out what is going on.
So much for my memory; wrong authority msg... I meant CPF3234 in the joblog. Anyway
you should probably just stick w/ CREATE statement to get an EVI.
Charles R. Pence
> This behavior of not being able to do a CRTDUPOBJ was not contemplated
> during the design. Our goal was to disallow anyone from trying to use
> an EVI as an access path through which data can flow. EVIs are only for
> creation of dynamic bit maps. That fact so noted, CRTDUPOBJ is not the
> same as CPYF since it really is an object operation and should have been
> allowed. Please make a formal request to IBM, so that we are nudged to
> do something about it.
Let's not get anyone's hopes up. Unless/until an EVI is assured to be eligible
for read like any LF <or SQL INDEX; albeit not by SQL> can be today <eg.
direct/seq/key reads w/ appropriate feedback>, I would not expect any change. As
it was never expected nor allowed to be generally read, it has never been tested.
As noted in a previous reply... best just to stick with SQL's CREATE vs CL's
CRTDUPOBJ to create an EVI.
Charles Wilt
.
Here are the answers to your questions:
.
1) Yes, CRTDUPOBJ is valid for any object of type *FILE. This includes
EVI's, which are a special type of logical file. The problem you
are encountering deals with the data security that is set when
the EVI is created.
2) The user cannot CRTDUPOBJ because CRTDUPOBJ requires that the user
have the data authority of Read to the object. To view the data
authorities to the object, do an EDTOBJAUT on the EVI. You will see
that the authority set for the user and *PUBLIC is USER DEF. By
pressing F11, you can toggle through the various object and data
authorities. You will see that there is no 'X' under Read for
data authorities. In fact, the system will not let you change
this. This is because of an attribute which is set for the file at
create time. This attribute, which you can see by doing a DSPFD on the
EVI, is Allow Read Operation, and it is set to NO for EVI's. The file
can not be read directly by the user - it is only meant to be read by
the query optimizer.
3) When someone with *ALLOBJ authority runs the CRTDUPOBJ command, no
authorities are checked, therefore they are not prevented from copying
the object. An *ALLOBJ user has all authority to every object on the
system, regardless of what is shown under EDTOBJAUT. Duplication of
EVI's using CRTDUPOBJ will require either
a) someone with *ALLOBJ do it
b) that the user be a member of a group that has *ALLOBJ authority
c) or that the user adopt *ALLOBJ authority from another user
though a CL program.
.
I hope this answers your questions.
Thank you for using IBM electronic support.
.
Regards,
.
Jaime Gaug
.
[My response]
Thanks for the clarification. Now the question is, are you going to
fix this so that it does not require *ALLOBJ to use the CRTDUPOBJ? I
don't think that this task should require *ALLOBJ authority.
Thanks,
Charles Wilt
Charles R. Pence
> <<SNIP>>
> 3) When someone with *ALLOBJ authority runs the CRTDUPOBJ command, no
> authorities are checked, therefore they are not prevented from copying
> the object. An *ALLOBJ user has all authority to every object on the
> system, regardless of what is shown under EDTOBJAUT. Duplication of
> EVI's using CRTDUPOBJ will require either
> a) someone with *ALLOBJ do it
> b) that the user be a member of a group that has *ALLOBJ authority
> c) or that the user adopt *ALLOBJ authority from another user
> though a CL program.
>
> [My response]
>
> Thanks for the clarification. Now the question is, are you going to
> fix this so that it does not require *ALLOBJ to use the CRTDUPOBJ? I
> don't think that this task should require *ALLOBJ authority.
or d) CRTAUTL OwnerAutl AUT(*ALL) /* By/For the App Owner */ RVKOBJAUT
FileName *FILE OwnerName *ALL
GRTOBJAUT FileName *FILE AUTL(OwnerAutl)
CRTDUPOBJ /* Gets Aut from *AUTL vs object... where no tie to ALWRead
*/
or e) As noted earlier, use SQL vs CRTDUPOBJ to work on this SQL object.
Charles Wilt
>
> or d) CRTAUTL OwnerAutl AUT(*ALL) /* By/For the App Owner */ RVKOBJAUT
> FileName *FILE OwnerName *ALL
> GRTOBJAUT FileName *FILE AUTL(OwnerAutl)
> CRTDUPOBJ /* Gets Aut from *AUTL vs object... where no tie to ALWRead
> */
>
> or e) As noted earlier, use SQL vs CRTDUPOBJ to work on this SQL object.
>
> Regards, Chuck
> All comments provided "as is" with no warranties of any kind whatsoever.
>
>
>
CRTDUPOBJ should not work without the extra work. I'll keep everyone
posted on what the offical word from IBM is.
Charles R. Pence
> Yep that seems to work just fine. However, IMHO there is no reason why
> CRTDUPOBJ should not work without the extra work. I'll keep everyone
> posted on what the offical word from IBM is.
Well, since I'll be giving the official word in this case...
So do you think we should special-case all EVIs for <only> CRTDUPOBJ? That is, to
allow CRTDUPOBJ w/out read authority <and since CRTDUPOBJ copies the aut, should it
'add' *READ>? Should we vitiate the ALWRead to *READ aut correlation <only> for
EVI? Then too for Save/Restore of EVIs? I am thinking that unless an EVI can be
'read', the best approach is to require the *AUTL or CREATE INDEX vs any coding
around the current design <ie. ALWRead not available; thus effecting no *READ aut>;
my time which IMO would be better spent correcting more important problems.
Tim
data authorities... Go back and fix that and this problem resolves itself.
Charles R. Pence wrote in message <36FFCAB3...@vnet.ibm.com>...
Charles R. Pence
> In my opinion, the mistake happened when IBM allowed logical files to have
> data authorities... Go back and fix that and this problem resolves itself.
Heh-heh.... Perhaps, but too late for that; and my comments about correction(s)
imply the same function as when there were no aut for LFs -- special case being
LFs <vs just EVIs>.
Charles Wilt
> Charles Wilt wrote:
>
> > Yep that seems to work just fine. However, IMHO there is no reason why
> > CRTDUPOBJ should not work without the extra work. I'll keep everyone
> > posted on what the offical word from IBM is.
>
> Well, since I'll be giving the official word in this case...
>
> So do you think we should special-case all EVIs for <only> CRTDUPOBJ? That is, to
> allow CRTDUPOBJ w/out read authority <and since CRTDUPOBJ copies the aut, should it
> 'add' *READ>? Should we vitiate the ALWRead to *READ aut correlation <only> for
> EVI? Then too for Save/Restore of EVIs? I am thinking that unless an EVI can be
> 'read', the best approach is to require the *AUTL or CREATE INDEX vs any coding
> around the current design <ie. ALWRead not available; thus effecting no *READ aut>;
> my time which IMO would be better spent correcting more important problems.
>
> All comments provided "as is" with no warranties of any kind whatsoever.
>
>
>
How about since the object does not allow its data to be read, CRTDUPOBJ
does not need to check for *READ authority to the data.
What about making the EVI some other object? Of course it's most likely
to late for that. But it seems to me that the object created by
CREATE ENCODED VECTOR INDEX
is not a logical file as we have come to know them.
I admit that this is not that big a deal, however IMHO this discussion is
very useful. Not only to like myself who have been using the AS/400
for only a few years. But to everybody else out there curious about the
new features that have been added. Also, perhaps you'll find it useful
in the future as you continue to add features.
Does anyone else following this have any comments?
Tim
checks as though they were device files. (Actually, IMO they shouldn't be
separate objects at all but rather just another index built over the
physical file with no separate existence at all other than a name)
Charles Wilt wrote in message ...
Charles R. Pence
> Many *FILE types do not have data authorities. IBM should do authority
> checks as though they were device files. (Actually, IMO they shouldn't be
> separate objects at all but rather just another index built over the
> physical file with no separate existence at all other than a name)
Actually device files do require *READ authority for CRTDUPOBJ; as well for most other actions --
other than presentation in a list which requires just *EXECUTE.
Perhaps the "another index" would have been a good approach... like a constraint.?.? However both
the SQL implementation and the possible future use of the index for reads would be
different/changing -- maybe not the desired outcome. For the SQL, it would have to have been other
than CREATE INDEX. If it had been ALTER TABLE like constraints. then if the possibility to add read
support later is desirable, then there would be two ways to create them <later adding CREATE INDEX>
-- some available to read, others <original created by ALTER, and not an external object> not.
Charles R. Pence
> How about since the object does not allow its data to be read, CRTDUPOBJ
> does not need to check for *READ authority to the data.
So for a CRTDUPOBJ of any SQL INDEX, I would then also ask the index object if it is an EVI. Then
if it is an EVI, I would just have to overlook the fact that there is no *READ authority -- actually
adopt it, as not even my OS code can subvert the security. Doing all that seems a little daft IMO,
just to make this one feature "work"; esp. given the next topic.
> What about making the EVI some other object? Of course it's most likely
> too late for that. But it seems to me that the object created by
> CREATE ENCODED VECTOR INDEX
> is not a logical file as we have come to know them.
Yes, too late. Currently an EVI is not just like any other LF. However there is no reason to
assume that you will never be able to perform read by key to <for example> get an RRN on an EVI in
the future. Thus in the future the *READ might appear with the Read Allow <per DSPFD; search ALW,
then -2 in control>
> I admit that this is not that big a deal, however IMHO this discussion is
> very useful. Not only to like myself who have been using the AS/400
> for only a few years. But to everybody else out there curious about the
> new features that have been added. Also, perhaps you'll find it useful
> in the future as you continue to add features.
I prefer the discussion; much better than dev decisions w/out good input from those who really use
it. I also attempted to give reasonable ideas like CREATE INDEX vs CRTDUPOBJ and using a *AUTL to
get the authority external to the object; so as to help ensure it "is not that big a deal." It is
also easier to discuss/show a dev perspective here with feedback than to simply answer the APAR as a
"permanent restriction"; hoping that the text provided in the answer and circumvention explains
enough.
Charles Wilt
> So for a CRTDUPOBJ of any SQL INDEX, I would then also ask the index object if it is an EVI. Then
> if it is an EVI, I would just have to overlook the fact that there is no *READ authority -- actually
> adopt it, as not even my OS code can subvert the security. Doing all that seems a little daft IMO,
> just to make this one feature "work"; esp. given the next topic.
*READ at all? If you were to try and do I/O you'll get an error from the
DBM correct? I mean even a user with *ALLOBJ can't do I/O to the object
even though he in effect has *READ to that object. 'Course as I
understand it, if the user has *ALLOBJ no other authority checks are
done. Which IMO, implies that the user has all the authorities.
> Yes, too late. Currently an EVI is not just like any other LF. However there is no reason to
> assume that you will never be able to perform read by key to <for example> get an RRN on an EVI in
> the future. Thus in the future the *READ might appear with the Read Allow <per DSPFD; search ALW,
> then -2 in control>
Get right on that...<grin>
> I prefer the discussion; much better than dev decisions w/out good input from those who really use
> it. I also attempted to give reasonable ideas like CREATE INDEX vs CRTDUPOBJ and using a *AUTL to
> get the authority external to the object; so as to help ensure it "is not that big a deal." It is
> also easier to discuss/show a dev perspective here with feedback than to simply answer the APAR as a
> "permanent restriction"; hoping that the text provided in the answer and circumvention explains
> enough.
Glad to hear it. Let me ask, was this an issue discussed during the
development of EVI's?
Charles R. Pence
> <<SNIP>> why bother to take away
> *READ at all? If you were to try and do I/O you'll get an error from the
> DBM correct? I mean even a user with *ALLOBJ can't do I/O to the object
> even though he in effect has *READ to that object. 'Course as I
> understand it, if the user has *ALLOBJ no other authority checks are
> done. Which IMO, implies that the user has all the authorities.
Yes the DB will prevent access even if the user has *READ <or inherits such via
some other method>. However this is a design point even lower than the
CRTDUPOBJ aut check; I would not even attempt to vitiate such a design.
> <<SNIP>>
> Let me ask, was this an issue discussed during the
> development of EVI's?
As the Allow values are part of the DB, and their affect on the Data rights for
object authority are known, I am sure all were confident that all would be
working as expected. They do work according to underlying design. However I
doubt that there was any specific thought to the use of CRTDUPOBJ not being
available w/out *AUTL or other action. This would not be a concern for a
query's implementation as it's authority to the index is via the data; as such
would not even be an issue in query testing.
Charles Wilt
>
> Yes the DB will prevent access even if the user has *READ <or inherits such via
> some other method>. However this is a design point even lower than the
> CRTDUPOBJ aut check; I would not even attempt to vitiate such a design.
vitiate (vīsh“ź-āt“) verb, transitive
vitiated, vitiating, vitiates
1. To reduce the value or impair the quality of.
2. To corrupt morally; debase.
3. To make ineffective; invalidate. See synonyms at corrupt.
Ok, I had to look that up (Thank you MS Bookshelf):-)
> As the Allow values are part of the DB, and their affect on the Data rights for
> object authority are known, I am sure all were confident that all would be
> working as expected. They do work according to underlying design. However I
> doubt that there was any specific thought to the use of CRTDUPOBJ not being
> available w/out *AUTL or other action. This would not be a concern for a
> query's implementation as it's authority to the index is via the data; as such
> would not even be an issue in query testing.
Well it has been an interesting discussion, and I know that this is way
way it will be. But for my own gratification, would you agree that it
does make sense that the owner of an object should be able to create a
duplicate of that object...assuming that the object can be duplicated of
course. In other words, I'm not crazy for wanting this am I?
Charles R. Pence
> <<SNIP>>
> Well it has been an interesting discussion, and I know that this is way
> way it will be. But for my own gratification, would you agree that it
> does make sense that the owner of an object should be able to create a
> duplicate of that object...assuming that the object can be duplicated of
> course. In other words, I'm not crazy for wanting this am I?
I agree given the specific scenario. Such a request is not crazy.
Just for fun... should a user that is the owner of an object, be able to delete
that object even without *OBJEXIST aut? Admittedly for the existence issue I
can not think of a condition outside of security <ie. not via DB> which
implicitly removes that right.
Some real questions: Given a user with ownership, but *EXCLUDE aut to an object:
Should the user be able to duplicate the object? View it? Sav/Rst it? Change
it <chg/mov/rnm/upd/ins/rmv>? Delete it? Refer to it <ie. *OBJREF>? See it in
a list or execute it? Currently a user is required to grant itself authority
first; only then allowing the user to do any of those <except maybe sav/rst>.
Karl Hanson
>
<snip
>
> Some real questions: Given a user with ownership, but *EXCLUDE aut to an object:
> Should the user be able to duplicate the object? View it? Sav/Rst it? Change
> it <chg/mov/rnm/upd/ins/rmv>? Delete it? Refer to it <ie. *OBJREF>? See it in
> a list or execute it? Currently a user is required to grant itself authority
> first; only then allowing the user to do any of those <except maybe sav/rst>.
>
This might(?) be useful to avoid the "shot in foot" syndrome. That is,
I own an object and therefore retain the ability to perform any
operation on it if/when needed. However I may want to revoke object
existence authority to prevent (for example) accidental deletion.
--
Karl Hanson