Re: ksh input control: read
On 12/14/06, Jacob Yocom-Piatt <[EMAIL PROTECTED]> wrote:
>This is a known problem with pdksh that the developers have stated
>they don't plan to change. `read' only updates the value of
>`testread' in the child shell process, not the parent.
>
>E.g., ``print "testing" | ( read testread; echo $testread )'' will
>work.
is there a ksh command that will print a variable, say $form_pw, with any
combination of "bad" characters (e.g. `,',",%,>,<,|) stored in it? this seems
like it would be a useful command since, AFAICT this issue is relatively common.
if no command exists, i can certainly write some C code to do it but would
rather see if it's doable using just ksh.
is there a list of all the characters you should escape/filter when writing
shell scripts?
You can use the ${varname} syntax (curly braces) to reference a
variable with special characters in the value.
If you're still on the CGI piece and want to filter out characters
from your input variables, you'll have to determine what those are
yourself, although ksh does support some advanced parameter editing
within the value of a variable. See ksh(1).
--
Darren Spruell
[EMAIL PROTECTED]
Re: ksh input control: read
Original message >Date: Thu, 14 Dec 2006 19:06:30 -0600 >From: "Matthew R. Dempsky" <[EMAIL PROTECTED]> >Subject: Re: ksh input control: read >To: misc@openbsd.org > >On Thu, Dec 14, 2006 at 12:55:42PM -0600, Jacob Yocom-Piatt wrote: >> print "testing" | read testread > >This is a known problem with pdksh that the developers have stated >they don't plan to change. `read' only updates the value of >`testread' in the child shell process, not the parent. > >E.g., ``print "testing" | ( read testread; echo $testread )'' will >work. > yeah, after further reading i found that pdksh and ksh behave differently w.r.t. child shells. the syntax you suggest above is what i've already fiddled with and see that it can work. is there a ksh command that will print a variable, say $form_pw, with any combination of "bad" characters (e.g. `,',",%,>,<,|) stored in it? this seems like it would be a useful command since, AFAICT this issue is relatively common. if no command exists, i can certainly write some C code to do it but would rather see if it's doable using just ksh. is there a list of all the characters you should escape/filter when writing shell scripts?
Re: ksh input control: read
On Thu, Dec 14, 2006 at 12:55:42PM -0600, Jacob Yocom-Piatt wrote: > print "testing" | read testread This is a known problem with pdksh that the developers have stated they don't plan to change. `read' only updates the value of `testread' in the child shell process, not the parent. E.g., ``print "testing" | ( read testread; echo $testread )'' will work.
ksh input control: read
i'm mostly done with a little ksh CGI script that allows users to change
their dovecot passwords after submitting an HTML form, but the issue of
input control has been giving me trouble.
to generate a new password hash the CGI script takes POSTed form data,
splits it into variables named FORM_username, FORM_password,
FORM_newpassword1 and FORM_newpassword2 then performs a couple operations:
newhash=`/usr/local/sbin/dovecotpw -p "$FORM_newpassword1"`
/usr/bin/sed "/$FORM_username/s/{HMAC-MD5}[a-z0-9]*:/$newhash:/g"
/etc/dovecot/virtual.passwd > /etc/dovecot/virtual.passwd
it's obviously a bad idea to use the form variables without putting them
through the ksh read f'n or something similar to catch characters that
should be escaped (`,',",%, etc.). the problem is pushing the variables
through read. a few links show read being used as
print "testing" | read testread
so that "echo $testread" should print "testing" after the read. this
does not work the same on the openbsd ksh CL and leaves testread empty.
however,
read testread < test.txt
works fine if test.txt is non-empty. this is very much circumlocutory
and i would rather not print passwords to a file only to read them back in.
advice on how best to pipe the $FORM_ variables into read is
appreciated. if read is not a safe method to filter for "danger" inputs,
do let me know.
cheers,
jake
