LINUX.ORG.RU

Релиз GNU C Library 2.17

 ,


0

2

Стало известно о выходе новой версии системной библиотеки glibc — 2.17.

Некоторые изменения:

  • добавлена поддержка архитектуры ARM AArch64;
  • порты glibc теперь содержатся в директории ports основного дерева исходных кодов проекта;
  • добавлена новая функция secure_getenv, которая предоставляет механизм безопасного доступа к переменным среды, возвращая NULL при запуске из процессов с флагами SUID/SGID;
  • оптимизация функций работы со строками: strstr, strcasestr и memmem;
  • минимально поддерживаемая версия ядра Linux — 2.6.16;
  • улучшена поддержка кросс-компиляции;
  • оптимизирована функция memcpy для архитектуры MIPS;
  • исправлено более ста ошибок.

GNU C Library полностью соответствует стандартам ISO C11 и POSIX.1-2008 и лежит в основе многих дистрибутивов Linux.

>>> Подробности

★★★★★

Проверено: maxcom ()

оптимизация функций работы со строками

strstr, strcasestr и memmem

так, а где strlcat/cpy/cmp?

anonymous ()

С нетерпением ожидаем форка от очередных гентушников, плачущих об отсутствии поддержки ядра 2.6.15 :-D

Lennart ()

Оппаньки! Спасибо...

... Годная новость. Готовлюсь к обновлению.

anonymous ()

новая функция secure_getenv, которая предоставляет механизм безопасного доступа к переменным среды, возвращая NULL при запуске из процессов с флагами SUID/SGID

В чём тут секьюрность, может кто-нибудь объяснить?

unsigned ★★★ ()
Ответ на: комментарий от Lennart

Какая же вредная харя у этого вашего Потцеринга на аватарке ;-)

gensym ★★ ()

оптимизация функций работы со строками: strstr, strcasestr и memmem

кто ставил сабж. флэш player работает?

anonymous ()

возвращая NULL при запуске

функции не запускаются, они выполняются.

niXman ★★ ()
Ответ на: комментарий от unsigned

Да все просто...

... какую бы переменную окружения Вы ни читали из suid/sgid приложения, возвратится NULL. Т.е., доступа к переменным окружения при использовании secure_getenv не будет. При использовании той же ф-ии в не-suid/sgid приложении, все будет работать нормально.

Это нужно на случай, если приложение _внезапно_ стало sgid/suid. Вот не было, а тут внезапно откуда-то соотв. флаг появился.

anonymous ()
Ответ на: Да все просто... от anonymous

Это не проясняет, чем плох доступ к переменным окружения из suid-программы.

Тем более, если автор использовал secure_getenv - значит, заботится о безопасности. А раз заботится - значит, ничего критичного читать из этих переменных не будет.

unsigned ★★★ ()

мдя, в Дебиан аж 2.13

в unstable

но в experimental УЖЕ 2.16

кто-нибудь ставил?

anonymous ()
Ответ на: комментарий от Lennart

C нетерпением ожидаем написания systemlibc, которая ускорит время загрузки еще на 50 микросекунд.

devl547 ★★★★★ ()

порты glibc теперь содержатся в директории ports основного дерева исходных кодов проекта;

мир перевренулся!

bootstrap builds without a previously built glibc.

А оно раньше не работало?

anonymous ()
Ответ на: комментарий от devl547

Не будет, потому что RH и так является основным разработчиком glibc.

Reset ★★★★★ ()
Ответ на: комментарий от unsigned

И "да" и "нет"...

... Авторы случаются просто сказочные дол*ы. Админы — еще «веселее». Например, я видел (правда один раз и недолго) как через переменные окружения передавались аутентификационные данные. За весь софт поручиться нельзя, а вот такого рода защита от идиотов не помешает.

Один из типсов при написании suid/sgid приложений заключался в «erase the execution environment and start fresh if it possible».

anonymous ()
Ответ на: комментарий от Reset

что как раз не мешает им запилить туда генератор QR-кодов.)

вообще RH ИМХО очень не кстати заболел NIH. и вместо допиливания и улучшайзинга существующих общепринятых в Линуксах средств и неизбежного сближения дистров, получается всё наоборот.

всякие эти полисикиты, которые такое ощущение, специально сделаны, чтобы затруднить, скажем, создание терминальных инфраструктур с десктопами юзеров и т.д. и т.п.

anonymous ()

Я смотрю всёпросралополимерщики уже вовсю резвятся. Им не нужно развитие, им нужна революция! Как хорошо что их пренебрежимо мало среди профессионалов, но как же их много среди околопрограммистской ботвы. Ужос. По теме, молодцы. Не по теме - бздунам кол в задницу, ибо в голове у них мозга нет.

alx_me ★★☆ ()

О, уже ебилды прилетели. Кто уже собрал?

Kindly_Cat ()

и кто сказал что она медленная? Очень даже быстрая. Гляньте сравнение с другими. Она не самая маленькая но и функций в ней гораздо больше ну и ISO C11, POSIX.1-2008 просто так не появляются.

stalkerg ★★★★★ ()
Ответ на: комментарий от devl547

А там будет веб-сервер с выполнением команд через qr-коды?

Deleted ()

минимально поддерживаемая версия ядра Linux — 2.6.16 Не, ну чего за вендастайл, а ? В винде и то срок поддержки оси лет десять, тут еще хуже Вот за каким .. нужна эта беспрерывная стильно модно молодежная гонка за собственных хвостом ?

anonymous ()
Ответ на: комментарий от anonymous

покажи неембед систему на которую ставится < 2.6.16 но не ставится 2.6.34 или какая там последняя

punya ★★ ()
Последнее исправление: punya (всего исправлений: 1)
Ответ на: комментарий от Lennart

Та ни, мы со страхом ждем, когда Поццеринг объявит планы о внедрении глибсов в системд. «Шобы было ищё быстрее!». И напишет для этого новый стандарт LNRT Desktop Linux Library Specification, которому и будет соответствовать в версии 1257.

dr_dobermann ()
Ответ на: комментарий от devl547

Нет, Лен-рт сделает иначе. Просто сольет базу udev+systemd+pulseaudio+libc и назовет это system. Без всяких d. С окружением - system/Linux. Останется только прикрутить туда шурупами гнум (уже близко) и будет прекрасная система gSystem/Linux.

anonymous ()
Ответ на: И "да" и "нет"... от anonymous

Re: И "да" и "нет"...

Например, я видел (правда один раз и недолго) как через переменные окружения передавались аутентификационные данные

А что, есть лучший способ? Ну кроме как иметь висящий в памяти демон и раздающий всем пароли, или постоянно вводить пароль самому, или хранить пароль в файле?

pv4 ★★ ()
Ответ на: комментарий от unsigned

Если смогли запустить прогу от рута, которая от рута запускаться не должна, то эта прога не сможет получить переменные среды (если она использует этот секьюрный вызов, конечно), т.е. отработает не так, как ожидается, злоумышленнику труднее будет добиться результата.

Профит копеечный, в принципе, но всё-таки.

ForwardToMars ()

Собралось без проблем. Поставилось, потестирую... :)

imul ★★★★★ ()
Ответ на: комментарий от imul

И зачем для тестирования glibc ждать выхода окончательной версии?

dinn ★★★★★ ()

POSIX?!

Linux прошёл SUS test? Вот это новость!

anonymous ()
Ответ на: комментарий от dinn

Потому что я — тестировщик любитель, а не профессионал.

imul ★★★★★ ()
Ответ на: Re: И "да" и "нет"... от pv4

Re: И "да" и "нет"...

... Я бы сказал что всё зависит от решаемой задачи. Правда, я оговорюсь что у меня с Qt/KDE ни как, так что я привёл гномоспецифичные варианты, надеюсь что для Qt/KDE есть что-нибудь аналогичное (если нет, то нахер его тогда использовать?).

Можно хранить (в случае с Gnome) пароли в Gnome Keyring (это да, демон), доступ к ключам через Seahorse. Это для начала. А дальше всё круче.

Можно (для локальной работы) подружить Gnome Keyring с PAM — https://live.gnome.org/GnomeKeyring/Pam

Можно подружить тот же Gnome Keyring с LDAP или заставить вводить пароль вручную (если захотели использовать в сетевом режиме, для доступа к некоему сетевому ресурсу). Вручную вот так можно например — http://nafiux.com/blog/2012/08/10/ldap-c-client-authentication-example-with-o... С LDAP можно сделать профили пользователей переносимыми между машинами в сети (вплоть до рабочего окружения DE).

Можно использовать связку LDAP+Kerberos+Gnome Keyring. Тот же evolution это умеет использовать, проверял.

Дофигищи вариантов, если честно, я _далеко_ не все перечислил. Для чисто консольных вариантов я бы предложил PAM (дружит и с LDAP и c Kerberos при необходимости), но пароли в таком случае лучше вводить вручную. Но только не через программное окружение, ну его на фиг...

anonymous ()
Ответ на: POSIX?! от anonymous

Re: POSIX?!

... А что тут не так? Или «полная совместимость» это Абсолютное и всепоглощающее Добро? :D

Разница между LSB (всем остальным по-моему, вполне достаточно уже существующей относительной совместимости с POSIX) сокрыта здесь — http://personal.opengroup.org/~ajosey/tr28-07-2003.txt

На практике я бы не советовал слепо следовать требованиям POSIX-only, а то там вот такие вот вещи проскальзывают:

106 2.1.4 gets

107 The LSB has deprecated the gets() function, whereas it is a first

108 class function in ISO/IEC 9945 and ISO/IEC 9899.

Ага. Отличное решение... Ну и так... «По мелочи», что называется некоторыми, отдельно взятыми товарищами в данном треде (весьма... «смело» я замечу, можно сказать безбашенно) не иначе как «старьём» и «быдлокодом». :D Интересно, что бы они сказали про такую тонкость, как пункт 3.1.10 df? И как назвали бы предписываемое поведение (указывать по умолчанию -k для df) в наши намного более просвещённые времена? :D

Пункт 3.3 вообще отсылает к поведению sh, в то время как в Linux sh это симлинк к bash. Продолжать там много и долго можно, по каждому пункту. Хотя, с момента написания того документа ситуация малость и поменялась, но не слишком сильно.

anonymous ()
Ответ на: И "да" и "нет"... от anonymous

Например, я видел (правда один раз и недолго) как через переменные окружения передавались аутентификационные данные.

Помоему прекрасный подход что не так?

quest ★★★★ ()
Ответ на: Re: POSIX?! от anonymous

в Linux sh это симлинк к bash

Не везде.

akk ★★★★ ()
Ответ на: Re: POSIX?! от anonymous

Re: POSIX?!

Тогда всё нормально. В новости надо исправить «полностью соответствует стандартам» на «очень напоминает стандарты» и всё путём. Нет ни соответствия стандартам ни серьёзного развития.

anonymous ()
Ответ на: комментарий от akk

Да, Вы правы...

... Не во всех случаях.

anonymous ()
Ответ на: Re: POSIX?! от anonymous

Re: POSIX?!

... Во-первых, в оригинальном тексте сказано:

It follows all relevant standards including ISO C11 and POSIX.1-2008.

Во-вторых, термин «очень напоминает стандарты» лучше наверное оставить коллегам из стана виндарасов, т.к. при том уровне соответствия оффтопа (например — http://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem и http://technet.microsoft.com/en-us/library/cc754351.aspx, последнюю ссылку лучше читать внимательно), это да... Это именно «напоминает» POSIX.

В третьих, из общеупотребительных POSIX-совместимых систем, типа Linux или FreeDSB/OpenBSD/NetBSD, ни одна не удовлетворяет _ВСЕМ_ стандартам POSIX, а их, ЕМНИП, 12 штук (по крайней мере, 1003.12, в своё время был стандартом на CDE (привет, Соляра!)). Однако это не мешает программистам писать POSIX-совместимый код. В случае с Linux совместимость будет процентов на 99.5, так что мелочами можно пренебречь. Если кто-то готов отказаться от вкусных пирогов и плюшек из gcc extensions, то пожалуйста — при компиляции ставите что-нибудь типа -std=c11 или в более длинной форме -std=iso9899:2011 и -Wpedantic и... дальнейший недостаток весьма полезных расширений, это ваша головная боль. Можете в коде определить уровень соответствия примерно так:

/* Для соответствия Single UNIX Specification v.3, оно же UNIX 03. */
#define _POSIX_SOURCE
#define _POSIX_C_SOURCE 200112L
#define _XOPEN_SOURCE 600
#define _XOPEN_SOURCE_EXTENDED 1

И... Получить тот же отказ от вкусных вещей из gcc extensions, доступных по просто #define _GNU_SOURCE.

Меня всегда забавляли и забавляют пуристы, считающие что 0.5% несовместимости отменяют остальные 99.5. И готовые «не замечать» развития только потому, что... Здесь я боюсь предположить что творится в их головах. Серьёзно. Для них важнее 0.5% несовместимости чем то, что POSIX определяет общий синтаксис и семантику API, но не концентрируется ни на самой реализации, ни на деталях реализации, где допустимы мелкие отступления от «линии партии». Но да... «сурьзное развитие отсутствует». :D /* Одного товарища тут вот унесло на alpinelinux, я думаю что к тому моменту, пока пожарю яишенки с беконом и кофейку заварю, он вернётся. :D Хотя, возможно, я и покурить успею ещё... :D */

В четвёртых, «полная совместимость» это своего рода чёрная метка. Та же Соляра была полностью совместима. RIP. AIX — полностью. RIP. Список можно продолжить. Кстати, в семействе полностью совместимых есть новичок — Mac OSX, что-то мне тревожно... :D

anonymous ()
Ответ на: Re: POSIX?! от anonymous

Re: POSIX?!

О том и речь, что стандарту не соответствуем. Свой стандарт нет сил народить, токмо чужой испортить. Но делаем вид, что всё серьёзно, важно.

anonymous ()
Ответ на: Re: POSIX?! от anonymous

Re: POSIX?!

... Пища бедновата жиром. Требую больше жира. :D

Какой «чужой стандарт», например? M$? Это они вроде по «промышленным стандартам» спецы. Во всех остальных (нормальных) случаях комитеты по стандартизации de jure закрепляют то, что уже есть de facto. Вся семейка стандартов POSIX так и родилась, если что. ;)

Ну а как не серьёзно и не важно, если французская жандармерия, как присела на ту же Ubuntu в 2005г., так и перевела своих 90000 копьютеров на неё на данный момент. Пруфы — http://www.ubuntu.com/products/casestudies/french-national-police-force-saves... и http://arstechnica.com/information-technology/2009/03/french-police-saves-mil...

Вероятнее всего у них самый популярный дистрибутив Linux это всё-таки не Android. :}

Мы же, пока нас всех всеобщее и тотальное Щщастье не накроет, можем по-раскладывать пасьянс «Косынку», да в «Сапёра» состязания устроить. По сети. :D Так что, кому «просто работать», а кому искать полноту соответствия стандартам. :}

anonymous ()

вышел линус на крыльцо
компильнуть себе глибцо

Spoofing ★★★★★ ()
Ответ на: Re: POSIX?! от anonymous

Одного товарища тут вот унесло на alpinelinux, я думаю что к тому моменту, пока пожарю яишенки с беконом и кофейку заварю, он вернётся. :D

Да не вернусь. Это песня, а не дистр, говорю же. Абсолютно ничего лишнего. И никаких совершенно нелогичных дефолтных системных зависимостей. После него любой арч с гентой кажется аццким bloatware. Короче, отличная демонстрация того, что системы без глибца вполне жизнеспособны.

border-radius ()
Ответ на: Re: POSIX?! от anonymous

В четвёртых, «полная совместимость» это своего рода чёрная метка.

Ахахаха!!!!111

Та же Соляра была полностью совместима. RIP. AIX — полностью. RIP. Список можно продолжить.

Впоследствии не значит вследствие.

Кстати, в семействе полностью совместимых есть новичок — Mac OSX, что-то мне тревожно... :D

Умер Ефим - да и хрен с ним.

akk ★★★★ ()
Ответ на: комментарий от border-radius

Ну не знаю...

... Я бы не стал рисковать. На embedded бизибокс и uClibc хорошо себя чувствуют. Жизнеспособно. А вот что будет на «большой» системе я без понятия. Возможно, что установка нового софта в такую систему будет напоминать забавный квест. Возможно что и не будет.

anonymous ()
Ответ на: комментарий от akk

В принципе, данный абзац...

... должен был быть огорожен тегом <joke>. Такого тега не нашел, пришлось обходиться так. :D

anonymous ()
Ответ на: Ну не знаю... от anonymous

Возможно, что установка нового софта в такую систему будет напоминать забавный квест. Возможно что и не будет.

Так вот, судя по репозиторию alpine, собранного под μClibc софта более чем достаточно для повседневки на ноуте. Установка нового софта из исходников, при наличии dev-пакетов, ничем не отличается от остальных систем. А вот о скайпе и прочем клозед-сорсе придётся забыть, ну да и хрен с ним. Дистр же security-oriented, а скайп и безопасность в принципе несовместимы.

border-radius ()
Ответ на: комментарий от border-radius

Кстати, про секьюрность...

... Серьёзно сомневаюсь в необходимости SSP & PAX на машине пользователя. На роутере/файере, там да без вопросов. А так, боюсь что прикладной софт надо будет долго тестировать, просто собрать его мало, т.к. всегда есть возможность заполучить проблемы. Иначе бы давно в Gentoo перешли бы на такую модель.

Скайп? Да, Вы правы. В топку сразу.

anonymous ()
Ответ на: Кстати, про секьюрность... от anonymous

И да, даже если кто-то умудрится создать жизнеспособный вирус хотя бы под x86 (с эскалацией привилегий и прочей фигнёй), он будет тупо бинарно несовместим с системой, где всё собрано на другой libc.

border-radius ()
Ответ на: комментарий от border-radius

А зачем делать вирус/троян...

... именно основываясь на glibc/uClibc? Для такого рода софта есть простой вызов через прямые сисколлы. Они реализованы в ядре, доступ к ним через int 80h (например гляньте здесь — http://asm.sourceforge.net/syscall.html, это для начала, некоторые вызовы поменялись, но подробно мне выписывать сейчас и здесь просто лень, можете поискать сами). Как с ними работать можно посмотреть тут для примера — http://www.win.tue.nl/~aeb/linux/lk/lk-4.html Хотя, переход к ассемблеру тут нужен только для того, чтобы получить максимально компактный код, в принципе, это можно всё сделать и на С. Потом, чтобы не сильно морочиться, использовать objdump. После objdump уже можно задумываться — использовать ли его выхлоп на ассемблере или оставить как есть.

Ядро у Вас будет всё то же, а вызовы API системы Вам и не нужны.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.