|
Oliver, Um, we are kind of blending issues here. I probably should have been more clear. If the object itself is secure can control certain aspects. My real point it that I would not rely on the restricted user access to control access to commands. My example may not be good but let's use CHGSYSVAL. A restricted user can't use that. I believe the default is for *PUBLIC to *EXCLUDE so that is actually good. But let's say access to the command is *USE or something like that. Using the PC remote command capability would allow a user to bypass the restricted user attribute. I think it might be important to differentiate between the security of your data, objects, and commands if that makes sense. While your security on your data may not be perfect (no offense) it isn't terrible. There is much worse out there. FYI - I have a 3rd party package that takes data files to *PUBLIC *EXCLUDE and then uses a group profile that has *CHANGE. Well guess what, most of the users on that system belong to that group. Horrible security. Not germane to your issue I just want you to know I'm not judging your setup. You are making efforts. Another point to make is that I believe in using multiple layers to security. I want the data secured but I also want to control who has access to the commands that work with that data or other objects. There are probably a 1,000 plus commands on your system (also interesting to note that access to the CPP can be just as critical). There are probably a much higher number of other objects (user profiles, files, outqs, etc.). While it may be extra work I would rather control both objects because it is likely that one or the other is going to missed. Others may not agree with this approach but I want the overlap. It creates more work but I'd rather have it that way. Hope that makes sense. Object security is great....but don't rely on the restricted user attribute at all. Michael Crump Saint-Gobain Containers 1509 S. Macedonia Ave. Muncie, IN 47302 (765)741-7696 (765)741-7012 f (800)428-8642 Slow email use this: mailto:mike.crump@xxxxxxxxxxxxxxxx Fast email that isn't company standard use this: mailto:mcrump@xxxxxxxxxxxxxxxx oliver.wenzel@xxxxxxxxxxxx ovartis.com To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> cc: 03/20/03 08:47 AM bcc: Please respond to Midrange Subject: Re: Security questions Systems Technical Discussion Mike, >2.) Think about the ability of users to run commands outside of the >command line process - remote commands, 3rd party software command >lines,etc. A PC user with the ability to run remote commands won't be >stopped by the limited access setting. I won't name names but we have a >3rd party software that provides their own menu system and command line >interface - guess what - limited capability is never brought into play. but object level security still applies for this kind of access, doesn't it? I see we will need to look into some of these security utilities. I understand, without some kind of exit-point programming, you can't stop this remote access? Thanks, OLiver _______________________________________________ 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
