• Subject: Re: your mail
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Thu, 25 Jan 2001 18:13:25 -0600 (CST)

Yes, doing that would solve this particular example.  Keep in mind,
though, that it was just one example.

What if, instead of another CRTPF command elsewhere in the library list,
you put a S/36 procedure?   For example, on my system there is a command
called 'QSYS/DEL' that deletes a file from the IFS.

There is also a (much older) S/36 procedure called 'DEL'.   When I do a
DEL it runs the S/36 proc, not the command in QSYS, despite that QSYS is
the first thing in my *libl.

What if CRTPF got accidentally deleted somewhere along the line?   If his
timing was correct, the 'evil user' from the previous message could still
usurp that command.

Of course, in this respect, OS/400 is a lot better than Unix or DOS.  In
those OSes you don't have seperate system & user library lists, and in DOS
(but not in Unix, usually) the current directory is always first.  I must
confess that I was "thinking in Unix mode" when I wrote my previous

On Thu, 25 Jan 2001, Peter Dow wrote:

> Hi Scott,
> Can't your scenario be handled by not allowing access to the CHGSYSLIBL
> command, nor to WRKSYSVAL, and by securing QSYS? *CURLIB in my experience
> comes after the system portion of the library list, as do product libraries
> and user libraries. If the untrusted user cannot change the library list of
> QSECOFR's job, it's unlikely they'd be able to have QSECOFR run their
> version of CRTPF (or any other system command).
> Regards,
> Peter Dow
> Dow Software Services, Inc.
> 909 425-0194 voice
> 909 425-0196 fax

| 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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.