В утилите GNU grep обнаружена (http://www.openwall.com/lists/oss-security/2012/12/22/1) опасная уязвимость, которая проявляется при обработке специально оформленного входного потока и может быть использована для инициирования отказа в обслуживании, а также, возможно, для выполнения произвольного кода. Подвержены выпуски утилиты GNU grep до версии 2.11. В выпуске 2.11 (http://www.opennet.ru/opennews/art.shtml?num=33249), вышедшем в начале марта 2012 года, эта уязвимость была исправлена (http://git.savannah.gnu.org/cgit/grep.git/commit/?id=cbbc1a4...), однако не было сделано никаких специальных анонсов о том, что ошибка имеет отношение к проблемам с безопасностью.
Проблема связана с переполнением памяти при обработке длинных строк (на архитектуре x86_64 длина опасной строки составляет порядка 2 Гб). Ошибка была случайно обнаружена (https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1091473) одним из пользователей Ubuntu, который пытался обрабатывать grep'ом вывод команды "ls -la" на своем хосте. Уязвимости присвоен идентификатор CVE-2012-5667.
Простейший метод проверки наличия уязвимости (проблема присутствует, если после выполнения нижеприведённой команды выводится ошибка сегментирования):
<font color="#461b7e">
$ perl -e 'print "x"x(2**31)' | grep x > /dev/null
</font>Debian и Ubuntu на данный момент еще не успели (https://security-tracker.debian.org/tracker/CVE-2012-5667) выпустить исправления. Однако, отдельные дистрибутивы, поставляющие свежие версии ПО, либо бэкпортирующие ключевые программы, не подвержены данной уязвимости (например, в Fedora 17 (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-5667) используется grep 2.14).
Опасность уязвимости усугубляется тем, что многие администраторы используют утилиту grep для автоматизированной обработки различных данных (в частности, системного лога). Часто такие процессы выполняются с административными привилегиями, что может оказаться фатальным в случае успешной атаки злоумышленника.
Дополнительно, стоит отметить, что в выпуске 2.11 присутствовали еще как минимум два (http://git.savannah.gnu.org/cgit/grep.git/commit/?id=4572ea4...) патча (http://git.savannah.gnu.org/cgit/grep.git/commit/?id=8fcf615...) которые, возможно, исправляют не менее опасные уязвимости. В настоящее время в отношении них производится проверка.URL: http://www.openwall.com/lists/oss-security/2012/12/22/1
Новость: http://www.opennet.ru/opennews/art.shtml?num=35700
В арче не сегфолтится.
В арче поди grep свежий.
Kubuntu 12.10 x64 Выводит сообщение что память закончилась, но без сегфолта...
perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: memory exhausted
$ grep --version
grep (GNU grep) 2.12
Аналогично в Ubuntu 12.10 (было б странно, если б не было аналогично).
> Аналогично в Ubuntu 12.10 (было б странно, если б не было аналогично).Зато пользователи 12.04 LTS срочно бегут прикрывать задницы сковородками и делать sudo chmod -x `which grep` :)
лучше sudo -x `which chmod`
...
>Kubuntu 12.10 x64Убунта перешла на микрософтовское обозначение архитектур?
> Убунта перешла на микрософтовское обозначение архитектур?Не вижу почеу у MS нельзя позаимствовать удачное изобретение. Коротко и ясно. И врядли подлежит патентованию.
> Не вижу почеу у MS нельзя позаимствовать удачное изобретение. Коротко и ясно.И криво.
> И криво.Да нормально. Названия типа х86-64 еще кривее, потому что какой оно там нафиг х86 с таким регистровым файлом и относительной адресацией, коей у х86 сроду не было? Да еще и длинное слишком. А AMD64 звучит странно, ибо не только амд. EM64T от интеля вообще похабщина какая-то. Ну и как предлагаете это называть? Как по мне, из всего этого зоопарка логичнее всего смотрится х64 как раз. Как гибрид x86 и AMD64. Хотя если есть какие-то объектиивные причины (торговая марка, или что там еще) или вы можете предложить более удачный и не менее короткий термин - озвучьте и я пересмотрю испольхование такого варианта.
> Названия типа х86-64 еще кривееЗато оно верное.
И это главное.
Кому не нравится, тот может откатиться от реверанса интелу и использовать оригинал — amd64 (как в генте к примеру).
А однобуквенное икс даже не отражает суть (как к примеру в х32 — прога 64-бита полноценно, кроме адресов. И сколько тупо рылых троллей сразу)
И это не говоря про титаники, армы ипр,ипр. Мелкосовту то похер, пока, они ничего больше не умеют.
> Да нормально. Названия типа х86-64 еще кривее, потому что какой оно там
> нафиг х86 с таким регистровым файлом и относительной адресацией, коей у
> х86 сроду не было?Если задуматься о происхождении "x86", то это сокращённое обозначение обобщения 8086..80486 как 80x86. Если его растянуть за уши ещё разик (как уже было с 16->32), то суффикс вроде "_64" вполне адекватно отражает суть происходящего.
А "x64" смысла лишено, это синтетика, потому что процессоры <prefix>*64, к которым бы она относилась, науке не известны (сходу вспоминается разве что DEC21164 со родичи, но это совсем другое).
> Да еще и длинное слишком. А AMD64 звучит странно, ибо не только амд.
И лучше бы интеловые горе-манагеры, которые сделали форк "не amd64", как следует проикались: с софтовыми затычками вместо нормального аппаратного IOMMU ещё несколько лет на их поделиях разгребались. Ну или по аналогии с IA32 приняли AA64. :)
> Ну и как предлагаете это называть?
Так и называю -- x86_64. Во избежание ухудшения зоопарка. Каждый раз ломая пальцы об это подчёркивание :-/
> x86_64на наркоманский смайлик похоже.
>> x86_64
> на наркоманский смайлик похоже.вам виднее
>> Убунта перешла на микрософтовское обозначение архитектур?
> Не вижу почеу у MS нельзя позаимствовать удачное изобретение. Коротко и ясно.
> И врядли подлежит патентованию.Потому, что оно мало того, что неудачное, так еще и технически не верное. Если Вы не помните, что обозначает x86, то я позволю себе напомнить, что Intel выпускал процессоры i8086, i80286, i80386, i80486, которые имели совместимую снизу вверх систему команд, и это семейство получило сокращенное наименование x86. Поскольку и AMD64, и EM64T - это дальнейшее развитие этого же семейства, то они, соответственно, получили наименование x86-64, которое однозначно указывает, что эта архитектура поддерживает совместимость с x86 и расширена 64-битным режимом.
x86-64 — первоначальный вариант. Именно под этим названием фирмой AMD была опубликована первая предварительная спецификация. Микрософт же, как всегда, "изобретает" свою терминологию, запутывая тем самым пользователей и представляя все так, будно это Микрософтовское изобретение. Маркетинг, одним словом. Но технически грамотным специалистам не к лицу использовать "маркетинговую" терминологию. x64 никакой смысловой нагрузки не несет, поскольку, кроме x86-64 есть еще достаточно много 64-битных архитектур, не совместимых программно с x86. Например: ARM64/AArch64 (ARMv8), Itanium, DEC Alpha...
$ perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: память исчерпана
$ rpm -q grep
grep-2.9-3.fc16.x86_64
$ cat /etc/redhat-release
RFRemix release 16.1 (Verne)
> grep: память исчерпанаЕе просто перл отожрал. Что не отменяет сути дыры.
Fedora 16 и ниже affected (согласно редхатовской багзилле).
>> grep: память исчерпанаОзначает ни что иное, как успешную блокировку проблему. Проблема в наличии если вместо сообщения об ошибке из грепа он сам сегфолтится.
> Означает ни что иное, как успешную блокировку проблему.Неа. Это означает, что данный демо-сплойт не работает. Не больше и не меньше. По поводу дыры в грепе он информации не несет.
Debian Squeeze i386 - ошибки сегментирования нет
Использую BSDGrep.% grep -V
grep (BSD grep) 2.5.1-FreeBSD
> Использую BSDGrep.
> % grep -V
> grep (BSD grep) 2.5.1-FreeBSDТам, наверное, это до сих пор не исправлено :)
> Там, наверное, это до сих пор не исправлено :)В девятке тоже:-(
там совсем другой код grep = http://svnweb.freebsd.org/base/head/usr.bin/grep/
Отличия в основном косметические, просто чтобы лицензию можно было поменять.Сегфолт воспроизводится, так что дыра скорее всего есть.
> Отличия в основном косметические, просто чтобы лицензию можно было поменять.
> Сегфолт воспроизводится, так что дыра скорее всего есть.печаль :(
Особенно печально, что freebsd security team подает признаки жизни от силы раз в год, поэтому ближайшие месяцы греп придется патчить вручную.
> Отличия в основном косметические, просто чтобы лицензию можно было поменять.GNU grep лежит по пути: /usr/src/gnu/usr.bin/grep/
BSD grep лежит по пути: /usr/src/usr.bin/grep/> Сегфолт воспроизводится, так что дыра скорее всего есть.
Дыра в GNU grep.
BSD grep тест не проходит.
Ложь, сегфолт не воспроизводится.
УМВР
>> Использую BSDGrep.
>> % grep -V
>> grep (BSD grep) 2.5.1-FreeBSD
> Там, наверное, это до сих пор не исправлено :)Что именно не исправлено?
Запустил пять минут назад. В GNOME System Monitor наблюдаю уменьшение потребления памяти с 3,5 до 1,8 ГБ. Команда всё ещё выполняется. Сколько по времени ждать сегфолта? (У меня ещё OpenOffice-3-devel в текстовой консоли собирается).
UPD1: Сейчас SWAP полез вверх — 62% занято. Оперативка 1,2 ГБ всего занята.
UPD2: Команда "perl -e 'print "x"x(2**31)' | grep x > /dev/null" молча завершила свою работу. Никаких сообщений в терминал не выдала. SWAP после 100% загрузки быстро освободился до 8% (общий размер SWAP 1,5 ГБ). Оперативная память сейчас занята 1,4 ГБ (19% от общего объёма).
FreeBSD 9.1-RELEASE #4: Sun Dec 23 19:53:44 MSK 2012% perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: (standard input): Недопустимый аргумент
% grep --version
grep (GNU grep) 2.5.1-FreeBSDСекфолта нет.
>Команда "perl -e 'print "x"x(2**31)' | grep x > /dev/null" молча завершила свою работуИ что? У меня аналогично, но не бздя
>SWAP после 100%
Э, теперь я знаю что ты брехал о том что ты джава-программист. Я подозревал. У меня например своп никгда не юзается. Не доходит до этого
$ cat /etc/debian_version
7.0
$ uname -a
Linux netbook 3.7.0 #1 SMP Wed Dec 12 20:49:24 MSK 2012 x86_64 GNU/Linux
$ grep --version
grep (GNU grep) 2.14
$ perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: memory exhaustedДаже не знаю. Debian sid
> grep (GNU grep) 2.14
> Даже не знаю. Debian sidА чего не знать. Пофикшено все, спи спокойно :)
Просто закончилась память. Сделай своп побольше.
Уязвимость проявляется при сегфолте.
> длина опасной строки составляет порядка 2 Гб
> пытался обрабатывать grep'ом вывод команды "ls -la"Странно, что никто еще не обратил на это внимания :)
> Странно, что никто еще не обратил на это внимания :)Маньяков желающих грепать 2 гига одним чихом в природе не так уж много.
# uname -a (Red Hat Enterprise Linux Server release 6.2 (Santiago))Linux 2.6.32-220.13.1.el6.x86_64 #1 SMP Thu Mar 29 11:46:40 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
# perl -e 'print "x"x(2**31)' | grep x > /dev/nullgrep: memory exhausted
исчерпал всю память (4ГБ), и записал в своп 100МБ и всё
совсем забыл# grep --version
GNU grep 2.6.3
Вот так почитаешь новости, и порадуешься, что мейнтейнер грепа свалил из FSF.
Потому что качество мейнтейнерства (особенно выпуска анонсов безопасности) у него было на высоте.
grep (GNU grep) 2.14gentoo - ok.
FreeBSD - segfault :(
Ну segfault и что дальше? Где демонстрация експлойта? "Возможно, вероятно"... Да почти все утилиты глючат и сегфолтятся, где демонстрация секьюрити хол? :)
> Ну segfault и что дальше? Где демонстрация експлойта?В следуюший раз лучше поставьте под сомнение "выскакивать одному на 20 гопов с битами - чревато". Так намного объяснение убедительнее для тех кто не в курсе что такое segfault и почему это происходит.
> grep (GNU grep) 2.14
> gentoo - ok.
> FreeBSD - segfault :(Это GNU grep. //ваш К.О.
> Это GNU grep. //ваш К.О.да я как бы понял. в портах, кста, гнугреп тоже дырявый
>> Это GNU grep. //ваш К.О.
> да я как бы понял. в портах, кста, гнугреп тоже дырявыйэто как? 2.12 же: http://www.freshports.org/textproc/gnugrep/
> это как? 2.12 же: http://www.freshports.org/textproc/gnugrep/Port: gnugrep-2.12_1
Path: /usr/ports/textproc/gnugrep
Info: GNU grep
Maint: gabor@FreeBSD.org
B-deps: gettext-0.18.1.1 libiconv-1.14
R-deps: gettext-0.18.1.1 libiconv-1.14
WWW: http://www.gnu.org/software/grep/действительно. чёрт куда ж я посмотрел-то? o_O
На Sisyphus не воспроизводится (x86_64/i586) -- там 2.14, на стабильных бранчах альта (t6/p6) воспроизводится -- там сейчас 2.10.
> На Sisyphus не воспроизводится (x86_64/i586) -- там 2.14, на стабильных бранчах альта
> (t6/p6) воспроизводится -- там сейчас 2.10.Хм. У меня пока 2.9-alt1, не воспроизводится.
> Хм. У меня пока 2.9-alt1, не воспроизводится.А в альте весь софт такой же ископаемый? oO
>> Хм. У меня пока 2.9-alt1, не воспроизводится.
> А в альте весь софт такой же ископаемый? oOПоднимите ясны очи на #21, а потом посмотрите на какой-нить стабильный редхат.
>>> Хм. У меня пока 2.9-alt1, не воспроизводится.
>> А в альте весь софт такой же ископаемый? oO
> Поднимите ясны очи на #21, а потом посмотрите на какой-нить стабильный редхат.У "стабилного редхета" сегодня-завтра это зафикся (если ещё не зафиксили), в отличие от "стабильного не-редхета".
> У "стабилного редхета" сегодня-завтра это зафикся (если ещё не зафиксили), в отличие
> от "стабильного не-редхета".блажен кто верует (с)
>> У "стабилного редхета" сегодня-завтра это зафикся (если ещё не зафиксили), в отличие
>> от "стабильного не-редхета".
> блажен кто верует (с)Да, кто верует - тот блаженный, согласен. Вменяемый - проверяет.
% apt-cache showpkg grep
Package: grep
Versions:
2.10-1 (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_precise_main_binary-amd64_Packages) (/var/lib/dpkg/status)
% perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: (standard input): Cannot allocate memoryдо этого тоже память заполняет
Ubuntu подвержены начиная с 12.04 и более ранние.
так не похоже как-то на сегфолт
Linux 3.2.0-23-generic-pae-uksm0.1.1 #36 SMP Wed Apr 25 12:07:52 CST 2012 i686 GNU/Linux
GNU grep 2.5.4
У меня вообще без каких либо ошибок выполняется, что я делаю не так?
каков обьём памяти у вас ? )) случаем не 32ГБ
# free -m
total used free shared buffers cached
Mem: 1939 1008 931 0 67 385
-/+ buffers/cache: 555 1384
Swap: 0 0 0
> i686 GNU/Linux
> что я делаю не так?on a typical 64-bit host
точно, не заметил
DragonFly loki 3.2-RELEASE DragonFly v3.2.2.2.g00f39-RELEASE #3: Tue Dec 18 08:10:26 YEKT 2012 root@loki:/usr/obj/usr/src/sys/LOKI x86_64vit@loki:/home/vit> grep -V
grep (GNU grep) 2.12
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.Written by Mike Haertel and others, see
<http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.ничего не сегфолтится
> grep (GNU grep) 2.12
> ничего не сегфолтитсяНеудивительно.
А вот BSD grep - в полный рост.
>> grep (GNU grep) 2.12
>> ничего не сегфолтится
> Неудивительно.
> А вот BSD grep - в полный рост.Это ложь.
>>> grep (GNU grep) 2.12
>>> ничего не сегфолтится
>> Неудивительно.
>> А вот BSD grep - в полный рост.
> Это ложь.Нет правда.
Нет - ложь.
>>>> grep (GNU grep) 2.12
>>>> ничего не сегфолтится
>>> Неудивительно.
>>> А вот BSD grep - в полный рост.
>> Это ложь.
> Нет правда.pkg_delete -x gnugrep
и спи спокойно дальше.
Кара Столмана в действии. Все потому что лидер ушел из ГНУ.
> Кара Столмана в действии. Все потому что лидер ушел из ГНУ.Скорее, наоборот. Его ушли из ГНУ за фиговое исполнение обязанностей, а он свел все это к политоте.
> Скорее, наоборот. Его ушли из ГНУ за фиговое исполнение обязанностей,
> а он свел все это к политоте.Не думаю, что в таком случае ему бы предлагали вернуться -- впрочем, про обязанности другая новость.
Спите дальше в своем мире RMS. Он всегда прав и это абсолютная истина. Это удобно - а главное думать не надо, за вас уже подумали.Только посмею себе напомнить что именно автор grep поднимал вопрос о том что в стандартах GNU должно быть прописано о написании безопасного кода. (см. предыдущий тред) и видимо не зря.
> Только посмею себе напомнить что именно автор grep поднимал вопрос о том
> что в стандартах GNU должно быть прописано о написании безопасного кода.
> (см. предыдущий тред) и видимо не зря.И, видимо, зря -- если он эту конкретную багу исправлял или видел. Потому что культура написания доверяемого кода подразумевает и чёткое информирование о характере и опасности найденных в уже написанном ошибок.
Впрочем, это уже предположения на предположения, что непродуктивно.
ОО.. вы много предупреждений видели в Linux kernel? в их stable обновлениях?
В лучшем случае краткое упоминание о buffer overflow, или null pointer deref ...
а то и просто "обновление крайне желательно".
и только когда уже кто-то показал проблему - появлется метка CVE...не так ли ?
> ОО.. вы много предупреждений видели в Linux kernel? в их stable обновлениях?Видал, но это проект IMHO хуже среднего в части работы с дырками и информацией о них.
Надеюсь, Вы когда-нибудь научитесь не передёргивать и не метаться из крайности в крайность, а вести осмысленное, полезное для себя и других обсуждение.
Так-то можно и Вашим любимым ораклом в нос ткнуть и молча посмотреть в глаза -- но ведь это не Ваша лично вина, зачем лишний раз пинать не того не о том в качестве примера ни о чём?
> Видал, но это проект IMHO хуже среднего в части работы с дырками и информацией о них.Ну так а чего тыкать в grep, когда это общая практика? Можно привести еще примеров из других проектов.
Такие изменений милион.> Надеюсь, Вы когда-нибудь научитесь не передёргивать и не метаться из крайности в крайность, а вести осмысленное, полезное для себя и других обсуждение.
Надеюсь вы научитись когда-то убирать свои комплексы к MSP и будете нести что-то осмысленное, не понятно в чем пытаясь упрекнуть маинтайнера grep - опять же не смотря на то что он поднимал вопрос о безопасном стиле кодирования.
Надеюсь вы научитесь не приводить какие-то пространные рассуждения о том что кто-то не прислал уведомления о дыре в безопастности. И тут же уходите в сторону когда вам тыкают что это распространенная практика. При этом еще умудряясь упрекнуть собеседника..> Так-то можно и Вашим любимым ораклом в нос ткнуть и молча посмотреть в глаза -- но ведь это не Ваша лично вина, зачем лишний раз пинать не того не о том в качестве примера ни о чём?
Ах какой молодец - вроде и пнул, но тут же "но это же не ваша вина"? Тебе бы чувак по НЛП писать бумажки..
Но что ж давай те потыкайте дистрибутивом линуха имени oracle. которые даже историю изменений ядра - делают открытой, в отличии от горячо вами любимого RedHat - который даже это преподносит как сервис для клиентов и за деньги.
И который предоставляет доступ к бинарным обновлениям совершенно бесплатно - в отличии опять же от RedHat.
Надо ли напоминать что T10 DIF/DIX есть в linux kernel - только из-за Oracle - а без него использовать за серьезных хранилищах - даже как-то стыдно.есть чем потыкать - кроме сопливого "Oracle это империя зла"?
PS, мы обсуждаем открытые проекты - и переход на закрытые мягко скажем не из той категории, это сравнивать теплое с мягким.. Или как один китаец недавно сравнил - байты с страницами.
> Ну так а чего тыкать в grep, когда это общая практика?Не общая, а часто встречающаяся. Есть ведь и внимательные апстримы.
> Надеюсь вы научитись когда-то убирать свои комплексы к MSP
От MSP потихоньку учусь Вас отличать.
> не понятно в чем пытаясь упрекнуть маинтайнера grep -
Его тут ни в чём не упрекаю -- можно лучше, но не обязан, строго говоря.
> опять же не смотря на то что он поднимал вопрос о безопасном стиле кодирования.В зависимости от его фактического отношения к конкретно этой баге это может только наложить на него ту самую обязанность -- говоришь, значит, так и делай.
> Надеюсь вы научитесь не приводить какие-то пространные рассуждения о том
> что кто-то не прислал уведомления о дыре в безопастности.Вы так ничего и не поняли. Наверное, невнятно опять написал :(
> И тут же уходите в сторону
Отнюдь.
> когда вам тыкают что это распространенная практика.
И это тоже не так, но раз уж заговорили о увиливании и практиках...
> Ах какой молодец - вроде и пнул, но тут же "но это же не ваша вина"?
О, а вот здесь поняли, надо же. И что теперь -- каждый раз строгачом работать? Не хочу.
> Тебе бы чувак по НЛП писать бумажки..
НЛП в своё время независимо открыл и через некоторое время себе запретил, поскольку это нарушение свободы человека.
[особо наивная реклама skip]> PS, мы обсуждаем открытые проекты - и переход на закрытые
И эти люди будут кому-то говорить про "уходите в сторону".
Мил человек, да мне как внедренцу в общем-то всё равно в первом приближении -- через что незваные гости придут. Это если информация о дырке уже публична, PoC или рабочий эксплойт есть, а вендор имеет обычай по кварталу в ухе ковыряться для выпуска затычки -- тогда вспоминаем про исходники и лезем сами или припахиваем кого более грамотного и достаточно доверенного. Когда они есть.
Вы бы это лучше понимали, если б тоже читали всякие bugtraq@ или full-disclosure@ да смотрели на код и с другой стороны. Он ведь не ради себя самого пишется.
Поймите правильно, пожалуйста.
> Не общая, а часто встречающаяся. Есть ведь и внимательные апстримы.Не встречал таких. Особенно когда исправляется ошибка без специального анализа и поиска.
Проходя мимо переписали код и получилось что бага ушла.> В зависимости от его фактического отношения к конкретно этой баге это может только наложить на него ту самую обязанность -- говоришь, значит, так и делай.
Зная поведение товарища Столмана - это все будет зависить от фазы луны и текущего настроения RMS.
Судя по новостям из соседнего треда - вместо ответа на конструктивную критику RMS предпочел сказать "Вали, еще вернешься". разве не так? я пропустил где-то конструктивный ответ RMS?
> Мил человек, да мне как внедренцу в общем-то всё равно в первом приближении -- через что незваные гости придут. Это если информация о дырке уже публична, PoC или рабочий эксплойт есть, а вендор имеет обычай по кварталу в ухе ковыряться для выпуска затычки -- тогда вспоминаем про исходники и лезем сами или припахиваем кого более грамотного и достаточно доверенного. Когда они есть.Вы помните что произошло когда один такой опытный поправил код OpenSSL? Из опыта работы могу сказать очень мало патчей со стороны могут быть включены без проблем и делают то что заявлено без backside эфектов. Даже ваши патчи по поддержке нового ядра в люстре - как бы так сказать.. хороши были только в роли чернового варианта.
А к слову о RedHat - при их выпендреже с скоростью поддержки - они не всегда выпускали исправления безопастности в первых рядах. Часто через 2-3 дня после того как патч с решением проблемы был известен публике.
Ранее, до взлома kernel.org, в changelog обычно можно было прочитать небольшие комментарии на тему что вот тут исправили потому что могла быть эскалация привелегий, тут локальный DOS ...А после взлома changelog-и стали сухими и невкусными
ну как... учатся у MS скрывать свои промахи. Кому будет интересно пользоваться продуктом в котором каждый день исправляют дыры с безопастностью ?
он заплыл жиром, его и выгнали :)
> Карма Столмана в действии.Скорее вот так :).
>Кара Столмана в действии. Все потому что лидер ушел из ГНУ.Нет. Это потому что он программирует на си. Спасибо кернигану и ричи за строка==указатель.
>>Кара Столмана в действии. Все потому что лидер ушел из ГНУ.
> Нет. Это потому что он программирует на си. Спасибо кернигану и ричи
> за строка==указатель.Жертва прогулов лекций? Запомни, двоешник: указатель - это указатель, и ничего больше, как ты этот указатель будешь использовать - целиком на ТВОЕЙ совести и на ТВОЕЙ ответственности, а не на совести Кернигана.
а есть какой-то другой пример, а то
perl -e 'print "x"x(2**31)' | wc -c
0
Ты себе перл сломал.>>> perl -e 'print "x"x(2**31)' | wc -c
2147483648
У меня:
$ perl -e 'print "x"x(2**31)'
<пусто>Может кто-то даст правильную команду?
> У меня:
> $ perl -e 'print "x"x(2**31)'
> <пусто>
> Может кто-то даст правильную команду?блин, выложите уже кто-нибудь файл из 2Г букв 'x' на файлообменник, а то ж ниасилят
Почему perl ни единого символа не выдал. Это нормальное поведение perl'а на 32-битной системе?
> Почему perl ни единого символа не выдал. Это нормальное поведение perl'а на
> 32-битной системе?чито?
> чито?А то что grep обрабатывает строку stdin, и если я не перенаправлю stdout perl'а в stdin grep'a, то эта строка должна появиться у меня на экране. А у меня та перлова команда ничего не экран не выдает. Почему?
>> чито?
> А то что grep обрабатывает строку stdin, и если я не перенаправлю
> stdout perl'а в stdin grep'a, то эта строка должна появиться у
> меня на экране. А у меня та перлова команда ничего не
> экран не выдает. Почему?покажи perl -v
ну и за одно аналогично:
# perl -e 'print "x"x(2**4)'
xxxxxxxxxxxxxxxx
$ perl -V
Summary of my perl5 (revision 5 version 16 subversion 1) configuration:
Platform:
osname=linux, osvers=3.6.2-gentoo-lix-k03, archname=i686-linux
uname='linux lix 3.6.2-gentoo-lix-k03 #3 smp sat oct 20 11:09:00 eest 2012 i686 intel(r) core(tm)2 cpu 6600 @ 2.40ghz genuineintel gnulinux '
...
$ perl -e 'print "x"x(2**4)'
xxxxxxxxxxxxxxxxТо есть, как я понял, при perl -e 'print "x"x(2**31)' происходит переполнение памяти где-то в недрах perl, но perl об этом просто не сообщает? Есть какой-то debug режим?
>[оверквотинг удален]
> osname=linux, osvers=3.6.2-gentoo-lix-k03, archname=i686-linux
> uname='linux lix 3.6.2-gentoo-lix-k03 #3 smp sat oct 20
> 11:09:00 eest 2012 i686 intel(r) core(tm)2 cpu 6600 @ 2.40ghz genuineintel
> gnulinux '
> ...
> $ perl -e 'print "x"x(2**4)'
> xxxxxxxxxxxxxxxx
> То есть, как я понял, при perl -e 'print "x"x(2**31)' происходит переполнение
> памяти где-то в недрах perl, но perl об этом просто не
> сообщает? Есть какой-то debug режим?ну для начала у тебя не x86_64 платформа
> ну для начала у тебя не x86_64 платформаЯ в курсе. Но мы сейчас говорим не о баге в grep, а об обработке перлом конструкции 'print "x"x(2**4)'. Как по мне, оно должно выдать либо результат, либо ошибку вне зависимости от платформы, или я чего-то не понимаю?
Я имел ввиду конструкции 'print "x"x(2**31)'
> Я имел ввиду конструкции 'print "x"x(2**31)'у тебя может быть включена какая-то защита от переедания памяти, которая просто киляет зажравшийся процесс. посмотри системные логи, если это так, то там должны быть записи.
в 32битной бунте перл себя так ведет
И не только в бунте. Вообще заставлять процесс x86-32 занять разом более 2Гб памяти - слегка моветон.
> Ошибка была случайно обнаружена одним из пользователей Ubuntu, который пытался обрабатывать grep'ом вывод команды "ls -la" на своем хостеЭто что ж за имена файлов такие, что они по два гига занимают?
> Это что ж за имена файлов такие, что они по два гига
> занимают?я вот тоже озадачен. чувак, видимо, решил весь вывод ls — вместе с -R по 100500 nfs-маунтов — склеить в одну строку и грепнуть. вот воистину: дай обезьяне гранату…
>> Это что ж за имена файлов такие, что они по два гига
>> занимают?
> я вот тоже озадачен. чувак, видимо, решил весь вывод ls — вместе
> с -R по 100500 nfs-маунтов — склеить в одну строку и
> грепнуть. вот воистину: дай обезьяне гранату…Убунтоводы, они такие.
Зато проблему выловил. За это спасибо ему.
> Debian и Ubuntu на данный момент ещё не успели выпустить исправления.Ой да лааадно! Зачем чушь писать-то..
Wheezy: Версия: 2.12-2PS ссылку видел.
> Ой да лааадно! Зачем чушь писать-то..
> Wheezy: Версия: 2.12-2Вы из будущего ? Релиза Wheezy ещё не было.
>> Ой да лааадно! Зачем чушь писать-то..
>> Wheezy: Версия: 2.12-2
> Вы из будущего ? Релиза Wheezy ещё не было.А уже со старым грепом...
>>> Ой да лааадно! Зачем чушь писать-то..
>>> Wheezy: Версия: 2.12-2
>> Вы из будущего ? Релиза Wheezy ещё не было.
> А уже со старым грепом...не старым, а опытным
>> А уже со старым грепом...
> не старым, а опытнымОпытный образец? :)
> Вы из будущего ? Релиза Wheezy ещё не было.Это как-то отрицает существование wheezy и возможность его скачать и поставить? Тем более, после freeze там ничего меняться не будет.
> Wheezy: Версия: 2.12-2Не говори, понаписали тут. У меня в Jessie уже grep версии 2.17.
>> Debian и Ubuntu на данный момент ещё не успели выпустить исправления.
> Ой да лааадно! Зачем чушь писать-то..Стабильный дебиан и убунту LTS вполне себе дырявые.
Или вы не отличаете обновления между дистрибутивами от обновлений безопасности?
FreeBSD 9.0-STABLE #0 r234897$ grep -V | head -1
grep (GNU grep) 2.5.1-FreeBSD$ perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: (standard input): Invalid argument
echo "WITH_BSD_GREP=true" >> /etc/src.conf
BSD Grep из FreeBSD 9.1-PRERELEASE на команду "perl -e 'print "x"x(2**31)' | grep x > /dev/null" никак не реагирует, никаких сообщений после выполнения не появляется.% grep -V
grep (BSD grep) 2.5.1-FreeBSD
% uname -a
FreeBSD roxy.fire 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r244694: Wed Dec 26 17:29:30 VOLT 2012 root@roxy.fire:/usr/obj/usr/src/sys/ROXY amd64
% grep -V
grep (GNU grep) 2.5.1-FreeBSD
% uname -rpo
FreeBSD 10.0-CURRENT amd64
% gcc -dumpversion
4.8.0
% clang -v
FreeBSD clang version 3.2 (branches/release_32 168974) 20121130
> % grep -V
> grep (GNU grep) 2.5.1-FreeBSD
> % uname -rpo
> FreeBSD 10.0-CURRENT amd64
> % gcc -dumpversion
> 4.8.0
> % clang -v
> FreeBSD clang version 3.2 (branches/release_32 168974) 20121130Имеет смысл заменить GNU grep на BSD grep, добавив строчку "WITH_BSD_GREP=true" в /etc/src.conf.
>> % grep -V
>> grep (GNU grep) 2.5.1-FreeBSD
>> % uname -rpo
>> FreeBSD 10.0-CURRENT amd64
>> % gcc -dumpversion
>> 4.8.0
>> % clang -v
>> FreeBSD clang version 3.2 (branches/release_32 168974) 20121130
> Имеет смысл заменить GNU grep на BSD grep, добавив строчку "WITH_BSD_GREP=true" в
> /etc/src.conf.от себя добавлю, что еще лучше добавить /etc/src.conf для нестабильных релизов :)
# Disable releng/release malloc(3)
MALLOC_PRODUCTION=yes
>[оверквотинг удален]
>>> FreeBSD 10.0-CURRENT amd64
>>> % gcc -dumpversion
>>> 4.8.0
>>> % clang -v
>>> FreeBSD clang version 3.2 (branches/release_32 168974) 20121130
>> Имеет смысл заменить GNU grep на BSD grep, добавив строчку "WITH_BSD_GREP=true" в
>> /etc/src.conf.
> от себя добавлю, что еще лучше добавить /etc/src.conf для нестабильных релизов :)
> # Disable releng/release malloc(3)
> MALLOC_PRODUCTION=yescd /usr/src/usr.bin/grep; make clean install clean
> cd /usr/src/usr.bin/grep; make clean install cleanhttp://svnweb.freebsd.org/base/release/8.3.0/usr.bin/ - где вы там grep нашли?
>> cd /usr/src/usr.bin/grep; make clean install clean
> http://svnweb.freebsd.org/base/release/8.3.0/usr.bin/ - где вы там grep нашли?Хотя вижу в мире о с 9-ки появился:
http://svnweb.freebsd.org/base/release/9.0.0/usr.bin/grep/
http://wiki.freebsd.org/BSDgrep
>> % grep -V
>> grep (GNU grep) 2.5.1-FreeBSD
>> % uname -rpo
>> FreeBSD 10.0-CURRENT amd64
>> % gcc -dumpversion
>> 4.8.0
>> % clang -v
>> FreeBSD clang version 3.2 (branches/release_32 168974) 20121130
> Имеет смысл заменить GNU grep на BSD grep, добавив строчку "WITH_BSD_GREP=true" в
> /etc/src.conf.BSD grep мне кажется или действительно намного производительное работает ?
>[оверквотинг удален]
>>> grep (GNU grep) 2.5.1-FreeBSD
>>> % uname -rpo
>>> FreeBSD 10.0-CURRENT amd64
>>> % gcc -dumpversion
>>> 4.8.0
>>> % clang -v
>>> FreeBSD clang version 3.2 (branches/release_32 168974) 20121130
>> Имеет смысл заменить GNU grep на BSD grep, добавив строчку "WITH_BSD_GREP=true" в
>> /etc/src.conf.
> BSD grep мне кажется или действительно намного производительное работает ?Нет. Он считается тормозным.
> Нет. Он считается тормозным.grep MapReduce БСД'шниками не был осилен ?
> BSD grep мне кажется или действительно намного производительное работает ?Мне кажется что вы только что открыли для себя панацею. Плацебо называется.
$ grep -V
grep (GNU grep) 2.12Ноут в нокауте!
> $ grep -V
> grep (GNU grep) 2.12
> Ноут в нокауте!Внезапно, два раза по два гига - это дофига оперативки.
для фряшников# cd /usr/src/usr.bin/grep
# make clean
# make
# make install clean
Нафига, он и так установлен - /usr/bin/bsdgrep
$ grep --version
grep (GNU grep) 2.10
$ perl -e 'print "x"x(2**31)' | grep x > /dev/null
Out of memory!Абсолютно ничего не произошло. ЧЯДНТ?
Устанавливает мало оперативы в комп.
> grep (GNU grep) 2.10
> Out of memory!
>ЧЯДНТ?Поставь прогркссивный 64-разрядный дистр!
хз,тоже не повторяетсяrain87@rain87-laptop:/tmp$ uname -a
Linux rain87-laptop 3.4.4-030404-generic #201206221555 SMP Fri Jun 22 19:56:36 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
rain87@rain87-laptop:/tmp$ perl -e 'print "x"x(2**31)' | wc -c
2147483648
rain87@rain87-laptop:/tmp$ perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: (стандартный ввод): Невозможно выделить память
rain87@rain87-laptop:/tmp$ free -m
total used free shared buffers cached
Mem: 7896 3653 4243 0 24 1858
-/+ buffers/cache: 1770 6125
Swap: 2859 1098 1761
rain87@rain87-laptop:/tmp$ grep -V
grep (GNU grep) 2.10
--cut--
rain87@rain87-laptop:/tmp$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.04.1 LTS
Release: 12.04
Codename: precise
a dmesg|tail
что говорит ?
у меня на 12.04.1 LTS секунд 15 отжирает память и сегфолтится
да, а на генте, где 2.14 все ок и отрабатывает за доли секунды.
да ничего не говорит, после этой команды никаких новых сообщений не появляется
uname -a
Linux 3.2.0-34-generic #53-Ubuntu SMP Thu Nov 15 10:48:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: (стандартный ввод): Невозможно выделить памятьесть уязвимость или нет? у меня 4 Гб рамы и куча свопа - но вывалилось с "Невозможно выделить память"
perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: память исчерпанаDebian Sid
# perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: (standard input): Недопустимый аргумент# grep -V
grep (GNU grep) 2.5.1-FreeBSDCopyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[root@sphynx ~]# uname -a
Linux sphynx 2.6.32-279.5.2.el6.x86_64 #1 SMP Fri Aug 24 01:07:11 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[root@sphynx ~]# perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: память исчерпанаCentOS 6.3, на площадке 2 Гб рамы. Слегка залез в своп при операции, но вроде живой.
На перезагруженной машине (после сборки свежего пакета ru-apache-openoffice-3.4.1425776,1) для повторного теста запустил: Thunderbird, Chromium, Терминал Xfce4, GNOME System Monitor.Ввёл su в терминале, запустил команду: perl -e 'print "x"x(2**31)' | grep x > /dev/null от рута.
Жду пять минут. Ничего не происходит. Потребление памяти в GNOME System Monitor — 706,2 МиБ (9%) из 7,5 ГиБ. Загрузка 4 ядер CPU гуляет от 20 до 40%.
На десятой минуте потихоньку начало есть SWAP (не более 20 МиБ). Потребление памяти почему-то сократилось до 606 МиБ (7,9%) из 7,5 ГиБ. Команда закончила свою работу без всяких сообщений.
% dmesg | tail
kbd3 at ukbd1
uhid0: <BTC USB Multimedia Keyboard, class 0/0, rev 1.10/1.00, addr 2> on usbus1
net0: link state changed to UP
drm0: <ATI Radeon HD 4200> on vgapci0
info: [drm] MSI enabled 1 message(s)
info: [drm] Initialized radeon 1.31.0 20080613
info: [drm] Setting GART location based on new memory map
info: [drm] Loading RS780/RS880 Microcode
info: [drm] Resetting GPU
info: [drm] writeback test succeeded in 1 usecs% grep -V
grep (BSD grep) 2.5.1-FreeBSD% uname -a
FreeBSD roxy.fire 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r244694: Wed Dec 26 17:29:30 VOLT 2012 root@roxy.fire:/usr/obj/usr/src/sys/ROXY amd64
У кого-то в openSUSE проявляется?
или старые версии grep-а не подвержены?perl -e 'print "x"x(2**32)' | grep x > /dev/null
- все выполняется мгновенно, без видимых изменений по памятиrpm -q grep
grep-2.7-3.1.i586head -1 /etc/SuSE-release
openSUSE 11.4 (i586)
> head -1 /etc/SuSE-release
> openSUSE 11.4 (i586)На архитектуре [i386] не проявляется.
>> head -1 /etc/SuSE-release
>> openSUSE 11.4 (i586)
> На архитектуре [i386] не проявляется.ты можешь максимум пару гигов оперативки выжрать на i386
> ты можешь максимум пару гигов оперативки выжрать на i386При сильном желании - тройку.
>> ты можешь максимум пару гигов оперативки выжрать на i386
> При сильном желании - тройку.А если пользоваться fork'ом и IPC - можно и терабайт в пределах одного приложения (не процесса!) сожрать, только это к grep имеет мало отношения :)
>>> ты можешь максимум пару гигов оперативки выжрать на i386
>> При сильном желании - тройку.
> А если пользоваться fork'ом и IPC - можно и терабайт в пределах
> одного приложения (не процесса!) сожрать, только это к grep имеет мало
> отношения :)обломаешся, адресного пространства не хватит.
> обломаешся, адресного пространства не хватит.Почему, собственно? Терабайт - это всего лишь ~1024 процессов с адресным пространством в 1 гиг. Вопрос хватит ли собственно у шины размера (насколько помню оно 36-битное в стандартной x86-32 архитектуре с PAE, т.е. всего лишь ничего - 64 гига), но в абсолютной теории катит. В любом случае >4G сожрать не особо трудно.
>> обломаешся, адресного пространства не хватит.
> Почему, собственно? Терабайт - это всего лишь ~1024 процессов с адресным пространством
> в 1 гиг. Вопрос хватит ли собственно у шины размера (насколько
> помню оно 36-битное в стандартной x86-32 архитектуре с PAE, т.е. всего
> лишь ничего - 64 гига), но в абсолютной теории катит. В
> любом случае >4G сожрать не особо трудно.PAE накладывает определенные ограничения, это не панацея.
> PAE накладывает определенные ограничения, это не панацея.Дык никто и не говорит, что это панацея :) Но если прицепить к PAE как минимум 42-44-битную шину, и создать нужное количество процессов - можно и на x86-32 терабайт выжрать :)
К слову говоря - x86-64 использует почти ту же структуру PT, что и PAE на x86-32.
>> PAE накладывает определенные ограничения, это не панацея.
> Дык никто и не говорит, что это панацея :) Но если прицепить
> к PAE как минимум 42-44-битную шину, и создать нужное количество процессов
> - можно и на x86-32 терабайт выжрать :)теоретически то, да.
>>> ты можешь максимум пару гигов оперативки выжрать на i386
>> При сильном желании - тройку.
> А если пользоваться fork'ом и IPC - можно и терабайтнельзя, на 386 не было PAE.
p.s. если, конечно, имелась в виду полезная нагрузка, а не CoW.
>>>> ты можешь максимум пару гигов оперативки выжрать на i386
>>> При сильном желании - тройку.
>> А если пользоваться fork'ом и IPC - можно и терабайт
> нельзя, на 386 не было PAE.
> p.s. если, конечно, имелась в виду полезная нагрузка, а не CoW.На 386SX, который на днях выкинули, сволочи, не было и математического сопроцессора, но дум2 шел.
И не говори, что почти 20 лет назад дум (1/2) - НЕ полезная нагрузка. :)
> На 386SX, который на днях выкинули, сволочи, не было и математического сопроцессора,
> но дум2 шел. И не говори, что почти 20 лет назад дум (1/2) - НЕ полезная нагрузка. :)На SX40 не шёл, а ползал или в окошке с почтовую марку, помнится; и нет, не полезная.
> На SX40 не шёл, а ползал или в окошке с почтовую марку,
> помнится; и нет, не полезная.Мммм. Авторитетно заявляю - на 386SX33 с 4 метрами - шёл прекрасно :) Рубались с приятелем по COM-порту через кабель, протянутый за окном с 3 на 1 этаж дома, у меня 386SX33, у него 386DX40 :)
> На 386SX, который на днях выкинули, сволочи, не было и математического сопроцессора,
> но дум2 шел.конечно, шёл. помнится, я пол-года движок сочинаял похожий, на чистом асме. а оказалось, оно на си…
> И не говори, что почти 20 лет назад дум (1/2) — НЕ
> полезная нагрузка. :)да ты что! дум — это завсегда полезно!
> нельзя, на 386 не было PAE.Ну ладно, уел, да. Я имел в виду x86-32, а не i386, естественно.
Зато вот если прибахать "правильную" EMM/EMS-плату (надеюсь, кто-то еще помнит, что такое EMM/EMS :) - можно и под досом с терабайт сожрать :)
софт надо специально пилить же, если верно помню.
>> ты можешь максимум пару гигов оперативки выжрать на i386
> При сильном желании - тройку.RH поддерживал 3.5/0.5 split.
> У кого-то в openSUSE проявляется?
> или старые версии grep-а не подвержены?Подвержены начиная с первой версии. Но для x86 демо-сплойт не работает.
> Но для x86 демо-сплойт не работает.Это не сплойт.
В 12.2 все нормально на х86_64
sysadmin:~$ grep -V
grep (GNU grep) 2.12
Copyright (C) 2012 Free Software Foundation, Inc.
Лицензия GPLv3+: GNU GPL версии 3 или новее <http://gnu.org/licenses/gpl.html>
Это свободное ПО: вы можете продавать и распространять его.
Нет НИКАКИХ ГАРАНТИЙ до степени, разрешённой законом.Авторы программы — Майк Хертель (Mike Haertel) и другие, см. <http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.
sysadmin:~$ cat /etc/issue.net
Debian GNU/Linux wheezy/sid
sysadmin:~$ perl -e 'print "x"x(2**31)' | wc -c
2147483648
sysadmin:~$ perl -e 'print "x"x(2**31)' | grep x > /dev/null
задумывается на пару секунд и, не выводит ни чего, хотя на ноуте все вешается и свопится, но на ноуте всего 4 гига памяти, из которых 3 в данный момент занято, а на десктопе 8 гигов.
dhcppc2:~# cat /etc/debian_version
5.0.10
dhcppc2:~# uname -a
Linux dhcppc2 2.6.26-2-686 #1 SMP Sun Mar 4 22:19:19 UTC 2012 i686 GNU/Linux
dhcppc2:~# grep --version
GNU grep 2.5.3Copyright (C) 1988, 1992-2002, 2004, 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.dhcppc2:~# perl -e 'print "x"x(2**31)' | grep x > /dev/null
dhcppc2:~#
$ perl -e 'print "x"x(2**31)' | grep x > /dev/null;
$ perl -e 'print "x"x(2**32)' | grep x > /dev/null;
grep: память исчерпана$ perl -e 'print "x "x(2 **31)' | sort -u > /dev/null;
sort: память исчерпана$ perl -e 'print "x "x(2 **31)' | rev > /dev/null;
rev: cannot allocate 4294967296 bytes: Невозможно выделить память
$ cat /etc/SuSE-release
openSUSE 12.2 (x86_64)
VERSION = 12.2
CODENAME = Mantis
# perl -e 'print "x"x(2**31)' | grep x > /dev/null
Segmentation fault (core dumped)# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)
версию грепа в студию# grep --version
у меня Red Hat Enterprise Linux Server release 6.2 (Santiago) сегфолта нет (GNU grep 2.6.3)
rh 6.2 просто не понял что такое 2**31 и не выполнил команду .... поставьте 2**30 и наслаждайтесь...
> rh 6.2 просто не понял что такое 2**31 и не выполнил команду
> .... поставьте 2**30 и наслаждайтесь...Хотя нет.. память тоже кончилась
Аналогично:Сожрал 2Гб оперативной секунд за 5, потом минуту пожирал 2Гб swapa, оставил чуток - 300 Мб и выкинул, что память исчерпана.
uname -a
Linux dejavu 3.6.8-hardened-hounfler #1 SMP Sat Dec 15 18:10:54 x86_64 Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz GenuineIntel GNU/Linuxgrep -V
grep (GNU grep) 2.14perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: память исчерпана
Gentoo x64, 6Gb RAM, grep 2.12
Команда отработала, не упала и ничего не написала, со статусом 0
> Gentoo x64Gentoo перешла на микрософтовское обозначение архитектур?
% grep --version
grep (GNU grep) 2.5.1-FreeBSD% uname -sr
FreeBSD 9.1-RELEASE% perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: (standard input): Invalid argument
У кого память не выделяется, запишите в файл. Или грепайте уже сразу /dev/random или /dev/sda1. Мне как-то пофиг, у меня левых файлов нет и grep (GNU grep) 2.12
Ибо нефиг парсить логи грепом когда есть православный PERL.
goga@ubuntu:~$ perl -e 'print "x"x(2**31)' | grep x > /dev/null
grep: (standard input): Cannot allocate memory
goga@ubuntu:~$
не сегфолт, но все равно хана?