Security level 40 - *SYSTEM/*USER object domains

[Guest.Visitor]

Background ... I have this tool I developed called ZWRKDTAQ. It was written in C/400 on V3R2 and probably uses some obscure techniques that I shouldn't have used. This tool is a "Work with Data Queues" command and allows you to view entries on a data queue. I posted the utility on my Web page (FTP'd SAVF) and kind forgot about it. I changed jobs and decided I'd like to use this tool. Didn't know if it would work on a V4R4 RISC box but I downloaded the SAVF, restored the objects and tried the command ... no joy! I got a MCH6801, didn't really look at it and just assumed (!!!!) that the obscure techniques didn't port ... I can live with that. BTW, I don't have the source or a C compiler now. I kinda forgot about it until I got an e-mail from someone who had downloaded the tool and had been using it successfully on V4R4 ... UNTIL THEY CHANGED TO LEVEL 40!!! They liked the tool and wanted to know if there was something they could do to get it to work. I checked and sure enough I'm at level 40 and after trying again I see that the MCH6801 is probably due to that fact. Reaseach ... In my research on level 40 (prior knowledge = ZIP) I see that now objects belong to either the *SYSTEM or *USER domain. My data queues are in the *SYSTEM domain. Programs, it appears, are either *SYSTEM, *INHERIT or *USER state (pardon me if this seems elementary, but it's new to me!). *SYSTEM objects cannot be accessed by a *USER program. This appears to be the crux of the problem. I'll continue my research but ... Questions ... 1) What controls whether an object is *SYSTEM or *USER? 2) Can I change an object from *SYSTEM to *USER? 3) Can I override this somehow? 4) Can I change my program to *SYSTEM? 5) Am I hooped? (or stooped?) Any other insights would be greatly appreciated!

[D.Handy]

Security level 40 - *SYSTEM/*USER object domains

Herb, *SYSTEM objects cannot be accessed by a *USER program. This appears to be the crux of the problem. Yup. 1) What controls whether an object is *SYSTEM or *USER? Short answer: OS/400 Some object types are always *SYSTEM state; some can go either way. Data queues and data areas are two examples of user-created objects which are always system state (AFAIK). Programs are an example of an object which can be either. Programs you create are user state; programs IBM provides may or may not be system state depending on what they do. 2) Can I change an object from *SYSTEM to *USER? This may be possible, but it would be the wrong way to try and circumvent this problem because every new *DTAQ created will automatically be system state. So you would have to do it each time. It would be better to use a supported interface; or see number 4 below. 3) Can I override this somehow? Use security level 30 or below. 4) Can I change my program to *SYSTEM? Yes. But the instructions for doing so are not supposed to be common knowledge, since system state programs can then do some of the things that security level 40 or 50 is trying to protect against. Still, this would be a better technique then changing an object's domain from *SYSTEM to *USER. Once the program was changed, it could be used for any exiting or future *DTQA whereas changing an object would only help the specific object. However, if you attempt to do a save/restore of the program it will lose its *SYSTEM state property. IOW, things like disaster recovery plans or even replication across multiple boxes becomes more complex since the program must manually be changed to *SYSTEM state. 5) Am I hooped? (or stooped?) That depends on whether or not you (read: your auditors) really want a user program to run in the system state. It is a much quicker fix than rewriting the utility to use a supported interface. But the "correct" way to do it use the QMHRDQM api which allows you to retrieve data queue entries in a non-destructive manner (i.e., they remain on the *DTAQ). If you want to continue this topic, email me offline at d_handy@bellsouth.net Doug

[Guest.Visitor]

Security level 40 - *SYSTEM/*USER object domains

Thanks for the info Doug. The main problems I have are no source code and no compiler. If I had those things I'd make the changes required. I don't really want to rewrite the tool ... too many other things to do ... but it would be nice to actually use it. The utility in question is fairly safe. The only potential damage it could do is to clear or delete a data queue and those act in a fairly typical "work with" fashion (ie. verify before acting) and use the standard APIs. From my research, it appears that some of the "obscure" (wrong?) things I did are, at level 40, blocked from being performed against data queues. There were a few, but the only one I really remember was doing a "matqats" (Materialize Queue Attributes?). I remember posting a question about this on the AS400 news group and getting a response (I think it was Kent Milligan, or someone else at that kinda level!) basically saying "That's not the intended use ...". OK, looks like he was probably right, but it's worked OK until now (even after having been ported from V3R2 -> V4R4 and converted to RISC). So ... I'm interested in changing my program to *SYSTEM. Can I do this without recompiling??

[D.Handy]

Security level 40 - *SYSTEM/*USER object domains

Herb, the only one I really remember was doing a "matqats" (Materialize Queue Attributes?). Close; MATQAT is the Materialize Queue Attributes instruction. This will get you the attributes of the *DTAQ (e.g. max len, current number of messages, etc.) but not the data queue entries themselves. If you didn't use the api's to get them, then you probably also have another portion of the code using unsupported (at level 40+) techniques. But there is a very good chance it would work if system state as well. So ... I'm interested in changing my program to *SYSTEM. Can I do this without recompiling?? Yes, in fact you'd need the program to already be compiled. As I mentioned in my last post, you also cannot save and restore the program without it reverting to the *USER state. So although you make it work on a given system by switching the states after the install, you cannot change your SAVF to include a *SYSTEM state version of the program. Please email me with the URL of the web page with your SAVF. Doug

[Guest.Visitor]

Security level 40 - *SYSTEM/*USER object domains

http://www.geocities.com/SiliconValley/Pines/9037 take the "AS/400 links" link How do I change my program to *SYSTEM????

[Guest.Visitor]

Security level 40 - *SYSTEM/*USER object domains

oooppppsss, I meant ... take the "AS/400 Utilities" link

[Guest.Visitor]

Security level 40 - *SYSTEM/*USER object domains

"Some object types are always *SYSTEM state, some can go either way." Rather than state, I believe you are talking about domain here. There is a brief write up on this in the Security Reference under Preventing the Use of Unsupported Interfaces (where the topic starts with "At security level 40 and higher,...). The advice of moving to APIs is right on. While some have found unsupported (by IBM) mechanisms to change programs to *system state, the IBM position is that *system and *inherit states are reserved for OS/400 IBM-supplied programs. Along these lines, there are system controls (such as system value QALWOBJRST, command CHKOBJITG, etc.) to help monitor such things.

[Guest.Visitor]

Security level 40 - *SYSTEM/*USER object domains

In a previous post I mentioned having got a "don't do that" advisory from someone on the newsgroup. This happened a few years ago and I thought maybe it was Kent Milligan ... but it could have been you Bruce. Sound familiar? Don't you remember every posting you respond to?? I concur with the switch to API approach ... I just don't have the time to redo it all. I was just looking for a quick fix (I would use it responsibly and am prepared to deal with the negatives).

[D.Handy]

Security level 40 - *SYSTEM/*USER object domains

Bruce, Rather than state, I believe you are talking about domain here. You are correct, of course. Sorry if it caused confusion for anyone. Doug

[Guest.Visitor]

Security level 40 - *SYSTEM/*USER object domains

Herb, I've written a set of RPGIV programs which provide similiar function. If you would like a copy of the source for these programs, you may contact me at mailto:jwhensley@peerlesschain.com

[Guest.Visitor]

Security level 40 - *SYSTEM/*USER object domains

Bruce, >>"Some object types are always *SYSTEM state, some can go either way." >Rather than state, I believe you are talking about domain here Can you clarify. I'm sure hat I mis-use these two term all the time. Have you time for a breif discussion about the differences between State and Domain? jte

[Guest.Visitor]

Security level 40 - *SYSTEM/*USER object domains

The two terms are decidedly intertwined, but I'll give it a shot. Domain is a characteristic of an object (that is, all objects have a domain) that controls which programs can access the object directly. Most objects are system domain, but a few (*USRSPC, *USRIDX, *USRQ, *PGM, *SRVPGM, *SQLPKG, etc.) can be either user domain or system domain. State is the attribute of a program (which includes subtypes such as *SRVPGMs) that determines the domain of objects that it can access directly. System state programs can access a user domain or system domain object; user state programs can only access a user domain object (directly).

[Guest.Visitor]

Security level 40 - *SYSTEM/*USER object domains

I recently downloaded the source code to the UNDEL utility(undeletes deleted records) from http://www.news400.com/sharewarefiles/undelsrc.zip. I would like to make some modifications to it. Some one else at my company downloaded the compiled objects(I'm not sure where). I have made my modifications and have gotten everything to compile, however there are a couple of programs that are in the *SYSTEM Program State. How can I get my modified version in this state? There seems to be some secret way to do this. I would appreciate it if someone would let me in on it. It is almost Christmas you know Thanks for your help Dale

[D.Handy]

Security level 40 - *SYSTEM/*USER object domains

Dale, "How can I get my modified version in this state? There seems to be some secret way to do this." Changing a program to system state is not terribly complicated. It involves patching just a single byte after the program has been compiled. The *real* secret is how the utility manages to get it onto your machine and still retain the system state flag. Normally, as soon as you patch a program and try and do any save/restore (to your own or another machine), the system will try and retranslate the program from the observable info. And it will also reset the program to user state. If no observable info is present, it will still reset it to user state. The ability to create a SAVF which will retain the system state attribute is not a widely known technique -- and IBM would like to keep it that way. The author of UNDEL does obviously know it. Perhaps Dave would compile your version for you and return you a version which can be saved/restored. Why are you modifying the program? Dave made a few fixes for date/time fields, and null capable fields too if I remember correctly. So if you have an old version and that is what you're trying to fix, just email Dave and he'll send you a more recent version. His email should be in the UNDEL docs. I'm out of town right now and don't have access to my machine with the latest version. Doug

[Guest.Visitor]

Security level 40 - *SYSTEM/*USER object domains

I didn't get any docs with the version I downloaded. Would you happen to have is e-mail? Thanks Dale