The Following 4 Users Say Thank You to iDont For This Useful Post: | ||
|
2011-07-09
, 11:23
|
Posts: 2,802 |
Thanked: 4,491 times |
Joined on Nov 2007
|
#92
|
Considering it is hard to believe someone has a $HOME > ~235 characters, and the fact that it you can't really gain anything by buffer underrunning
The Following 3 Users Say Thank You to lma For This Useful Post: | ||
|
2011-07-09
, 12:03
|
Posts: 2,802 |
Thanked: 4,491 times |
Joined on Nov 2007
|
#93
|
Aha, you are absolutely correct, I completely missed that all this time :-(
The Following 2 Users Say Thank You to lma For This Useful Post: | ||
|
2011-07-09
, 15:22
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#94
|
The Following 3 Users Say Thank You to iDont For This Useful Post: | ||
|
2011-07-09
, 17:17
|
|
Moderator |
Posts: 7,109 |
Thanked: 8,820 times |
Joined on Oct 2007
@ Vancouver, BC, Canada
|
#95
|
The Following 2 Users Say Thank You to qole For This Useful Post: | ||
|
2011-07-09
, 23:38
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#96
|
In histcopy(), check the result of the input fopen and bail out before clobbering the output file.
I don't agree that if the user doesn't have a ~/.ash_history, or have an empty one, or /tmp is full etc they should be locked out. Return instead of exit?
The tmppath directory shouldn't be created with mode 0777 (predictable filenames in world-writable directories are a bit exploitable), 0700 will do.
One could trigger a buffer overrun by feeding the shell a long $HOME (though that doesn't give any additional privileges). Using concat_path_file for tmppath would be safer than malloc/strncat here.
The Following User Says Thank You to Estel For This Useful Post: | ||
|
2011-07-13
, 12:00
|
Posts: 1,680 |
Thanked: 3,685 times |
Joined on Jan 2011
|
#97
|
aaaaaaaaaa^Mbbbbbbbbb^Mccccccccccc^Mdddddddd
The Following 2 Users Say Thank You to vi_ For This Useful Post: | ||
|
2011-07-13
, 14:19
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#98
|
Great work. We can expect this to hit repos ASAP (in fact, when sending anything into them will be possible), right?
I believe I 'may' have found a bug or something. If I try to cat a file that contains a windblows newline character '^M' I lose everything preceeding that character.
Nokia-N900:~# echo 'aaaaaaaaaa^Mbbbbbbbbb^Mccccccccccc^Mdddddddd' > testfile && cat testfile aaaaaaaaaa^Mbbbbbbbbb^Mccccccccccc^Mdddddddd
The Following 3 Users Say Thank You to iDont For This Useful Post: | ||
|
2011-07-13
, 14:37
|
Posts: 2,802 |
Thanked: 4,491 times |
Joined on Nov 2007
|
#99
|
If I try to cat a file that contains a windblows newline character '^M' I lose everything preceeding that character. I.e. if I try to cat a file containing:
I will only see dddddddd as the result.Code:aaaaaaaaaa^Mbbbbbbbbb^Mccccccccccc^Mdddddddd
|
2011-07-13
, 15:08
|
Posts: 1,680 |
Thanked: 3,685 times |
Joined on Jan 2011
|
#100
|
curl -A "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3" http://www.metoffice.gov.uk/weather/uk/surface_pressure.html | sed -e 's#<[^>]*>##g' | grep "chilly"
So you're right about Nokia's patch not introducing the problem. However, it doesn't fix it either.
Regarding your comments on my patch:
Thanks for the review. I'll create an v2 when I've got the time for it (probably later today).
Just an idea: you could add something like:
Last edited by iDont; 2011-07-09 at 10:40.