On Sun, 26 Jan 2014 17:19:46 -0500, Peter Relson wrote: >> >>buffer overflow. ... > >There already is such an indication. Return code 8 from ASASYMBM indicates >that there is not enough room in the target buffer for the substituted >result. That can occur, today, only if an exploiter provides their own >symbol table (whether in conjunction with system symbols or not) and that >symbol table does not limit symbol value length to the symbol name length. >The system will put into the buffer as much as fits. > >It is likely that return information would be provided to indicate "how >big would I have had to make the target buffer in order to have had room". > A la snprintf()? But how would the hypothetical caller use the information if the service expects a standard (fixed) length buffer?
>Providing an approach that would overcome the fixed-length record length >(such as for JCL or parmlib member reads) or the 126-byte command length >limitation is not likely to happen. At best I could envision "reject >entirely". > IOW, the current interface does not pass the buffer length? >It is possible that we could consider a message in some of these cases >(when there is a common point that the detection would occur), but since >we would not be likely to implement a confirming WTOR "truncation >occurred, do you want to continue" (in part because there might not be >anyone around to react to such a WTOR), a message would therefore indicate >"truncation occurred, we used the truncated result, we hope that that use >did not cause trouble, change and try again if you don't like what >happened". > Or, could the caller hypothetically deal with RC=8? How would this all hypothetically play with JCL's DSN=, PARM=, and PARMDD (i.e. symbol substitution in SYSIN)? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
