|
I don't know what we're disagreeing on - what you said is exactly the point I was making. IBM should _NOT_ be using CRTPF - especially not the QSYS qualified version - for the FTP PUT command. It _IS_ a security loophole, and one that was introduced somewhere between V3R2 and V4R2. But I _WOULD_ expect that the interface (from the FTP client's point of view) remains the same from one release of OS/400 to the next. Tim > -----Original Message----- > From: Patrick Townsend [SMTP:townsend@patownsend.com] > Sent: Sunday, October 18, 1998 10:22 PM > To: MIDRANGE-L@midrange.com > Subject: Re: FTP server authority issue > > Tim, > > We agree on so much! I suppose we'll have to disagree on this one. I > think that FTP should not even use the CRTPF command in QSYS for its > file services. To me the fact that FTP uses CRTPF represents a > potential > security hole in FTP and I wouldn't be surprised to see IBM address > this > in the future. And as you've already discovered it is dangerous to > assume that the underlying file interface for FTP will be the same > from > one release of OS/400 to another.... > > Good luck! > Patrick > > Tim McCarthy wrote: > > > > Patrick, I don't think you've grasped the issue :-) . Let's say you > want > > to change the use of the CRTPF command and create your own - perhaps > to > > force some defaults for all users. The way to do this would be to > > duplicate this command into a library higher in the list than QSYS, > then > > you could modify the validity checking program or whatever. Now, to > stop > > users from circumventing this and simply using the original version > (by > > specifying QSYS/CRTPF) you need to remove the authority of users to > the > > version of CRTPF in QSYS. Well once you've done this your FTP users > are > > hosed because they can't use PUT anymore because they're not > authorized > > to QSYS/CRTPF! No exit point routine will work because it can't > restore > > the necessary authority. > > > > > -----Original Message----- > > > From: Patrick Townsend [SMTP:townsend@patownsend.com] > > > Sent: Friday, October 16, 1998 1:25 PM > > > To: MIDRANGE-L@midrange.com > > > Subject: Re: FTP server authority issue > > > > > > Tim, > > > > > > Interesting. I can sympathize with the desire to have the FTP > server > > > use > > > native AS/400 commands and the library list, but if I were IBM I > > > certainly wouldn't want to sign up for that restriction. That > would > > > prevent them from doing anything to improve performance or > security at > > > a > > > lower level. When you use FTP what you really want is for it to > obey > > > all > > > of the rules (transfer and authority) in the RFCs for FTP, yes? > > > > > > Also, if FTP used the library list to resolve the use of the CRTPF > > > command, wouldn't this introduce the possibility of additional > > > security > > > problems? Let's say I'm a creative programmer who knows that > NEWSYS is > > > in the system library list above QSYS and that FTP uses CRTPF and > the > > > system library list. Wouldn't I be able to create a command called > > > CRTPF > > > in NEWSYS that did just about anything I wanted? > > > > > > I think that IBM's roadmap for FTP use and security is pretty > clear. > > > You > > > might like or dislike exit points, but I think that's the place to > > > implement security. If you want a user to execute a CRTPF command > you > > > should use the appropriate FTP command to pass this through and > have > > > your exit point security module allow or disallow the command. > > > > > > Patrick > > > > > > Tim McCarthy wrote: > > > > > > > > I disagree with your point that FTP commands run on the server > > > should > > > > obey a different set of authority rules. If I override certain > > > commands > > > > by using a library higher in the list than QSYS and apply > certain > > > > authority rules to those commands, I would not expect users to > be > > > able > > > > to circumvent those rules by signing on using FTP instead. > That's > > > > effectively what's happening here. PUT is an FTP command but it > > > utilizes > > > > OS/400 commands directly - restrictions on the use of CRTPF > > > inherently > > > > effect PUT, but users use two different versions of this CRTPF > > > depending > > > > on whether they use it directly or through PUT. I too can also > see > > > IBM's > > > > reason for wanting to use a "pure" version of the CRTPF command, > > > however > > > > I think using the command directly is the wrong approach - > > > referencing > > > > the command authority from the *LIBL while utilizing the QSYS > CPP > > > would > > > > be better. Now the user has a dilemma - authorize everyone using > FTP > > > to > > > > CRTPF in QSYS (what they were trying to prevent) or pre-create > all > > > files > > > > that users PUT to (which is unrealistic in their environment) - > not > > > even > > > > an FTP exit routine will solve this one. > > > > > > > > > -----Original Message----- > > > > > From: Patrick Townsend [SMTP:townsend@patownsend.com] > > > > > Sent: Friday, October 16, 1998 12:41 AM > > > > > To: MIDRANGE-L@midrange.com > > > > > Subject: Re: FTP server authority issue > > > > > > > > > > Tim, > > > > > > > > > > I can see your point about QSTRUPPGM. It is a different class > of > > > > > program. > > > > > > > > > > I'm a little confused about the issue of creating files via > put > > > and > > > > > crtpf. I can see why IBM would want to force the put command > to > > > use > > > > > the > > > > > QSYS version of the crtpf command (or any internal version > that > > > they > > > > > want to use). Put is an FTP concept that has to obey FTP > rules, > > > not > > > > > AS/400 rules. If they let you change the way FTP works with > put it > > > > > would > > > > > open up nasty support issues for IBM, wouldn't it? > > > > > > > > > > The command interface in FTP lets you run commands that are > unique > > > to > > > > > the particular server. You can execute the crtpf command or > any > > > other > > > > > user-written command you want. No one expects that the command > > > > > interface > > > > > will work the same from one platform to another. > > > > > > > > > > Am I missing something? > > > > > Patrick > > > > > > > > > > Tim McCarthy wrote: > > > > > > > > > > > > But this is not the way it used to work. I've tried this on > a > > > V3R2 > > > > > machine > > > > > > and it uses the library list to determine the command to use > > > > > (CRTPF). > > > > > > Whether you are using exit points or not, you still have the > > > > > exposure that > > > > > > two different authority levels exist for a single user > depending > > > on > > > > > whether > > > > > > they attempt a file creation option from the command line or > use > > > the > > > > > PUT > > > > > > command through the FTP server. (QSTRUPPGM doesn't fall into > the > > > > > same > > > > > > category of program - I would expect it to reference a > reliable > > > base > > > > > set of > > > > > > commands.) > > > > > > > > > > > > > > > > > > At 12:00 PM 10/15/98 -0700, you wrote: > > > > > > >Hi Tim, > > > > > > > > > > > > > >It is quite common for IBM to qualify command usage to > point to > > > the > > > > > QSYS > > > > > > >library. Just look at the source for QSTRUPPGM as an > example. > > > It > > > > > would > > > > > > >probably take an IBM'er to really answer this question. I > would > > > > > suspect > > > > > > >that the proper way to secure FTP is with the exit points. > Gee, > > > who > > > > > do > > > > > > >we know who has an FTP security product <g> ??? > > > > > > > > > > > > > >Patrick > > > > > > >-- > > > > > > >IBM AS/400 communications, FTP automation, and network > security > > > > > > >software and consulting services. > > > > > > > > > > > > > >mailto:townsend@patownsend.com > > > > > > >http://www.patownsend.com > > > > > > > > > > > > > >Tim McCarthy wrote: > > > > > > >> > > > > > > >> Can anyone verify this: > > > > > > >> > > > > > > >> A customer is running the OS/400 FTP server under V4R2. > They > > > have > > > > > a > > > > > > >> modified system library list that has a user library > NEWSYS > > > prior > > > > > to QSYS > > > > > > >> in which they have created versions of IBM commands - one > of > > > > > which is > > > > > > >> CRTPF. All users have had authority revoked to the > original > > > > > commands in > > > > > > QSYS. > > > > > > >> When running an FTP session, users authorized to the new > > > CRTPF > > > > > command can > > > > > > >> run the command QUOTE RCMD CRTPF QGPL/myfile etc.. > > > successfully. > > > > > However > > > > > > >> when they try to use PUT to send to the file QGPL/myfile > > > (which > > > > > does not > > > > > > >> exist) they get an error "Unable to open or create target > > > file > > > > > MYFILE in > > > > > > >> library QGPL". I've checked out the FTP server job log > and > > > the > > > > > library list > > > > > > >> does include NEWSYS in the library list ahead of QSYS. > > > > > Interestingly the > > > > > > >> server joblog error states "Not authorized to command > CRTPF > > > in > > > > > library > > > > > > >> QSYS". Has the FTP server program changed to use the > CRTPF > > > > > command in QSYS > > > > > > >> explicitely? If so, this would seem to be a security > hole. > > > > > > >> > > > > > > >> Tim > > > > > > >> Tim McCarthy > > > > > > >> TrailBlazer Systems Inc. > > > > > > >> AS/400 E-Commerce communications > > > > > > >> +--- > > > > > > >> | This is the Midrange System Mailing List! > > > > > > >> | To submit a new message, send your mail to > > > > > MIDRANGE-L@midrange.com. > > > > > > >> | To subscribe to this list send email to > > > > > MIDRANGE-L-SUB@midrange.com. > > > > > > >> | To unsubscribe from this list send email to > > > > > > MIDRANGE-L-UNSUB@midrange.com. > > > > > > >> | Questions should be directed to the list > owner/operator: > > > > > > david@midrange.com > > > > > > >> +--- > > > > > > >+--- > > > > > > >| This is the Midrange System Mailing List! > > > > > > >| To submit a new message, send your mail to > > > > > MIDRANGE-L@midrange.com. > > > > > > >| To subscribe to this list send email to > > > > > MIDRANGE-L-SUB@midrange.com. > > > > > > >| To unsubscribe from this list send email to > > > > > MIDRANGE-L-UNSUB@midrange.com. > > > > > > >| Questions should be directed to the list owner/operator: > > > > > david@midrange.com > > > > > > >+--- > > > > > > > > > > > > > Tim McCarthy > > > > > > TrailBlazer Systems Inc. > > > > > > AS/400 E-Commerce communications > > > > > > +--- > > > > > > | This is the Midrange System Mailing List! > > > > > > | To submit a new message, send your mail to > > > > > MIDRANGE-L@midrange.com. > > > > > > | To subscribe to this list send email to > > > > > MIDRANGE-L-SUB@midrange.com. > > > > > > | To unsubscribe from this list send email to > > > > > MIDRANGE-L-UNSUB@midrange.com. > > > > > > | Questions should be directed to the list owner/operator: > > > > > david@midrange.com > > > > > > +--- > > > > > > > > > > -- > > > > > > > > > > IBM AS/400 communications, FTP automation, and network > security > > > > > software and consulting services. > > > > > > > > > > mailto:townsend@patownsend.com > > > > > http://www.patownsend.com > > > > > +--- > > > > > | This is the Midrange System Mailing List! > > > > > | To submit a new message, send your mail to > > > MIDRANGE-L@midrange.com. > > > > > | To subscribe to this list send email to > > > MIDRANGE-L-SUB@midrange.com. > > > > > | To unsubscribe from this list send email to > > > > > MIDRANGE-L-UNSUB@midrange.com. > > > > > | Questions should be directed to the list owner/operator: > > > > > david@midrange.com > > > > > +--- > > > > +--- > > > > | This is the Midrange System Mailing List! > > > > | To submit a new message, send your mail to > > > MIDRANGE-L@midrange.com. > > > > | To subscribe to this list send email to > > > MIDRANGE-L-SUB@midrange.com. > > > > | To unsubscribe from this list send email to > > > MIDRANGE-L-UNSUB@midrange.com. > > > > | Questions should be directed to the list owner/operator: > > > david@midrange.com > > > > +--- > > > > > > -- > > > > > > IBM AS/400 communications, FTP automation, and network security > > > software and consulting services. > > > > > > mailto:townsend@patownsend.com > > > http://www.patownsend.com > > > +--- > > > | This is the Midrange System Mailing List! > > > | To submit a new message, send your mail to > MIDRANGE-L@midrange.com. > > > | To subscribe to this list send email to > MIDRANGE-L-SUB@midrange.com. > > > | To unsubscribe from this list send email to > > > MIDRANGE-L-UNSUB@midrange.com. > > > | Questions should be directed to the list owner/operator: > > > david@midrange.com > > > +--- > > +--- > > | This is the Midrange System Mailing List! > > | To submit a new message, send your mail to > MIDRANGE-L@midrange.com. > > | To subscribe to this list send email to > MIDRANGE-L-SUB@midrange.com. > > | To unsubscribe from this list send email to > MIDRANGE-L-UNSUB@midrange.com. > > | Questions should be directed to the list owner/operator: > david@midrange.com > > +--- > > -- > > IBM AS/400 communications, FTP automation, and network security > software and consulting services. > > mailto:townsend@patownsend.com > http://www.patownsend.com > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to > MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > david@midrange.com > +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.