Re: your mail

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


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
+---