|
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. -- [ Picked text/plain from multipart/alternative ] Thanks John. Then, if what you say is correct (rights stored on the user profile), why do I still lose those rights when restoring a file in the same library ? Said differently, if we save a file on a tape, and then just restore this same file on the original data, we still loose those rights. Daniel -----Original Message----- From: security400-request@midrange.com [mailto:security400-request@midrange.com] Sent: jeudi, 23. août 2001 19:01 To: security400@midrange.com Subject: Security400 digest, Vol 1 #9 - 7 msgs Send Security400 mailing list submissions to security400@midrange.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.midrange.com/cgi-bin/listinfo/security400 or, via email, send a message with subject or body 'help' to security400-request@midrange.com You can reach the person managing the list at security400-admin@midrange.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Security400 digest..." Today's Topics: 1. Re: Authority annoyances, continued... (John Earl) 2. Re: Restore and loss of private rights (John Earl) 3. Re: Welcome to the Security400 Mailing List @ Midrange.com ! (John Earl) 4. Re: Authority annoyances, continued... (John Earl) 5. RE: Authority annoyances, continued... (Joe Giusto II (E-mail)) 6. RE: Authority annoyances, continued... (Bale, Dan) 7. Re: Authority annoyances, continued... (John Earl) --__--__-- Message: 1 From: "John Earl" <johnearl@powertechgroup.com> To: <security400@midrange.com> Subject: Re: [Security400] Authority annoyances, continued... Date: Wed, 22 Aug 2001 17:39:46 -0700 Organization: The PowerTech Group Reply-To: security400@midrange.com Dan, I agree with the poster who asked why this was different/better than just creating an adopted authority program. It can be significantly less secure than an adopted authority routine. > Create a user on the system (eg. BACKUPUSER) with no password (password > *NONE). Ensure this user has the required authority to do the back up. A > good way to achieve this is to put the user into the QSECOFR group, make the > group the owner of all objects created by this user. > > Create a job description that will be used to submit the back up job to > batch. Ensure that the USER parameter of the job description specifies the > new user (eg. USER(BACKUPUSER)). Any job submited to batch using this job > description will then run under the new user profile. This last line may be much truer than you wish. On a security level 30 machine, this JOBD would be usable by any user, for any purpose they desire, unless you specifically restrict access to the JOBD. If you choose this route, please be sure to secure the JOBD to *PUBLIC *EXCLUDE and then specifically give the user who will be submitting this job *USE authority to the JOBD. This will prevent other users from misappropriating this JOBD. It may not prevent the original user from mis-using this JOBD though. Once you give them authority to use the JOBD, it may be difficult or impossible to control what they use the JOBD for. An adopted authority routine that does a very specific thing, and adopts the necessary authority for a finite period of time can provide a much more secure route to your destination.. jte -- John Earl - VP & CTO The Powertech Group 253-872-7788 johnearl@powertechgroup.com www.powertechgroup.com --__--__-- Message: 2 From: "John Earl" <johnearl@powertechgroup.com> To: <security400@midrange.com> Subject: Re: [Security400] Restore and loss of private rights Date: Wed, 22 Aug 2001 22:53:10 -0700 Organization: The PowerTech Group Reply-To: security400@midrange.com Daniel, > Hi all. When restoring a database, we lose private rights on objects. Anyone > having an idea how to solve this issue ? If it's a system bug, does a > solution come with V5R1 ? > This question is close enough to a question that I just answered on the Midrange-L that I hope you don't mind me just replaying that question and answer. If this doesn't answer your question, let me know and I'll take another shot at it. ### > I was wondering why when I save a program with private > authorities to a save file and then restore the > program to a different library I lose the private > authority. Actually, you don't lose the private authorities, they are right where they always were. :) Private authorities to an object (such as a file) are stored in the user profile object, and not in the file object. That's an important thing to understand about private authorities... So if you save a copy of file "ITEM", and then restore the file to another library, PHIL's profile still records the fact that he has *ALL authority to the original "ITEM" file. This newly restored file "ITEM" in a new library? Well User Profile PHIL has never even been told that this new file exists, so it can't be authorized to it. (This would mean that the suggested RSTAUT command would not work either) If you want object level security, then every time you introduce a new object to your system you must manage the authority to that new object. There is no "automatic security feature" that will guess what authority you want assigned to new objects, so you have to do it yourself. In this case I would recommend that after you restore the object, run the GRTOBJAUT command, and use the original "ITEM" file as a "referenced object". It's one extra step, but it will get you want you want. ### jte -- John Earl - VP & CTO The Powertech Group 253-872-7788 johnearl@powertechgroup.com www.powertechgroup.com --__--__-- Message: 3 From: "John Earl" <johnearl@powertechgroup.com> To: <security400@midrange.com> Subject: Re: [Security400] Welcome to the Security400 Mailing List @ Midrange.com ! Date: Wed, 22 Aug 2001 22:57:27 -0700 Organization: The PowerTech Group Reply-To: security400@midrange.com Phil, > On the Code/400 list we were talking about how to open an IFS file from Code > Edit. It opens a java app that allows you to browse the IFS (including > qsys.lib) The folders do not need to be shared through OpsNav, a version of > client access that supports mapping drives doesn't need to be installed, and > the QFWPSERVER authorization list doesn't prevent access to qsys.lib. > > I have had no trouble securing folders other than qsys. QSYS, however, is > much more difficult because many apps require users to do things users > normally aren't authorized to do (ADDPFM, RMVPFM etc) so authority is lax. > > Has anyone gone though another vendor's app, changed all file authorities to > public *exclude, change the owner to a profile that can't sign on, and then > change the initial programs to use adopted authority *owner? I can't answer the question as asked, but it is worth noting that the IFS does not support the adopted authority concept. You can define your programs as USRPRF(*OWNER), it's just that the adopted authority will not work when accessing objects outside of QSYS.LIB. You'll have to use some other authority method in the IFS. jte -- John Earl - VP & CTO The Powertech Group 253-872-7788 johnearl@powertechgroup.com www.powertechgroup.com --__--__-- Message: 4 From: "John Earl" <johnearl@powertechgroup.com> To: <security400@midrange.com> Subject: Re: [Security400] Authority annoyances, continued... Date: Thu, 23 Aug 2001 00:58:44 -0700 Organization: The PowerTech Group Reply-To: security400@midrange.com > QSYSOPR wouldn't be able to do that. It checks to see if you have authority > to the user profile on the job description. The sbmjob would fail with a > "not authorized to profile" message. True for QSECURITY level 40 machines. But if the machine is at QSECURITY level 30 or less, the sbmjob would be successful if the user merely has *USE authority to the JOBD. jte > > -----Original Message----- > From: Buck Calabro [mailto:Buck.Calabro@commsoft.net] > Sent: Wednesday, August 22, 2001 12:00 PM > To: security400@midrange.com > Subject: RE: [Security400] Authority annoyances, continued... > > > >Create a job description that will be used to submit the > >back up job to batch. Ensure that the USER parameter > >of the job description specifies the new user (eg. > >USER(BACKUPUSER)). Any job submited to batch > >using this job description will then run under the new user profile. > > Not a guru, so this may be wrong, but can't I (a mere operator) do: sbmjob > cmd(grtobjaut...) jobd(backupjobd) and give myself authority to anything? > Why is this better than having the CL program adopt required authority? > _______________________________________________ > This is the Security Administration on the AS400 / iSeries (Security400) > mailing list > To post a message email: Security400@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/security400 > or email: Security400-request@midrange.com > _______________________________________________ > This is the Security Administration on the AS400 / iSeries (Security400) mailing list > To post a message email: Security400@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/security400 > or email: Security400-request@midrange.com > -- John Earl - VP & CTO The Powertech Group 253-872-7788 johnearl@powertechgroup.com www.powertechgroup.com --__--__-- Message: 5 From: "Joe Giusto II \(E-mail\)" <juicenetdps@crosswinds.net> To: <security400@midrange.com> Subject: RE: [Security400] Authority annoyances, continued... Date: Thu, 23 Aug 2001 09:48:57 -0400 Reply-To: security400@midrange.com If memory serves me correctly, didn't the SYS38 default objects to public exclude (or maybe it was just use)? I seem to remember always having trouble with object authority when ever we changed employees. As the new operator would run jobs during the first week or so, we would have to keep granting object authority to files as programs blew up. This was of course before we learned about the group profiles which eliminated that need once implemented. We granted proper authority to the group profiles and then just started adding profiles to the group when new person came. Joe Giusto II Programmer/Analyst Ritz Camera Beltsville, MD 301-419-3209 x347 410-813-2812 x347 -----Original Message----- From: security400-admin@midrange.com [mailto:security400-admin@midrange.com] On Behalf Of John Earl Sent: Wednesday, August 22, 2001 8:04 PM To: security400@midrange.com Subject: Re: [Security400] Authority annoyances, continued... <snip> Now, we sell exit programs, and make our living (in part) off of this "hole" that was opened up - but I must insist - please, don't blame IBM. They didn't do it. The hole was created by us (you and I ) and all the other developers and (especially) application vendors that built our systems to rely on "menu security". IBM told us not to do it. IBM gave us object level security. We just chose not to use. I agree that the /400 world is in a very messy place with respect to security, I just don't think you can saddle IBM with the blame. <snip> jte -- John Earl - VP & CTO The Powertech Group 253-872-7788 johnearl@powertechgroup.com www.powertechgroup.com --__--__-- Message: 6 Subject: RE: [Security400] Authority annoyances, continued... Date: Thu, 23 Aug 2001 10:15:27 -0400 From: "Bale, Dan" <D.Bale@handleman.com> To: <security400@midrange.com> Reply-To: security400@midrange.com This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Um, wait, I'm getting lost here. Was it me you were responding to? (Not too many Dan's on the list, so I'm assuming.) Are you differentiating an adopted authority program from an adopted authority routine? If so, how are they different? Dan Bale IT - AS/400 Handleman Company 248-362-4400 Ext. 4952 D.Bale@Handleman.com > -----Original Message----- > From: John Earl [SMTP:johnearl@powertechgroup.com] > Sent: Wednesday, August 22, 2001 8:40 PM > To: security400@midrange.com > Subject: Re: [Security400] Authority annoyances, continued... > > Dan, > > I agree with the poster who asked why this was different/better than > just creating an adopted authority program. It can be significantly > less secure than an adopted authority routine. > > > Create a user on the system (eg. BACKUPUSER) with no password > (password > > *NONE). Ensure this user has the required authority to do the back > up. A > > good way to achieve this is to put the user into the QSECOFR group, > make the > > group the owner of all objects created by this user. > > > > Create a job description that will be used to submit the back up job > to > > batch. Ensure that the USER parameter of the job description > specifies the > > new user (eg. USER(BACKUPUSER)). Any job submited to batch using > this job > > description will then run under the new user profile. > > This last line may be much truer than you wish. On a security level > 30 machine, this JOBD would be usable by any user, for any purpose > they desire, unless you specifically restrict access to the JOBD. > > If you choose this route, please be sure to secure the JOBD to *PUBLIC > *EXCLUDE and then specifically give the user who will be submitting > this job *USE authority to the JOBD. This will prevent other users > from misappropriating this JOBD. > > It may not prevent the original user from mis-using this JOBD though. > Once you give them authority to use the JOBD, it may be difficult or > impossible to control what they use the JOBD for. > > An adopted authority routine that does a very specific thing, and > adopts the necessary authority for a finite period of time can provide > a much more secure route to your destination.. > > jte > > > -- > John Earl - VP & CTO > The Powertech Group > 253-872-7788 > johnearl@powertechgroup.com > www.powertechgroup.com --__--__-- Message: 7 From: "John Earl" <johnearl@powertechgroup.com> To: <security400@midrange.com> Subject: Re: [Security400] Authority annoyances, continued... Date: Thu, 23 Aug 2001 07:57:35 -0700 Organization: The PowerTech Group Reply-To: security400@midrange.com > Um, wait, I'm getting lost here. Was it me you were responding to? > (Not too many Dan's on the list, so I'm assuming.) Yes > Are you differentiating an adopted authority program from an adopted > authority routine? If so, how are they different? No - No difference in my book. jte --__--__-- _______________________________________________ This is the Security Administration on the AS400 / iSeries (Security400) digest list To post a message email: Security400@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/security400 or email: Security400-request@midrange.com End of Security400 Digest ********************************************************************** This E-mail and any files transmitted with it are confidential and intended for the exclusive use of the addressee(s) only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender immediately. **********************************************************************
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
