Вышло (http://www.kernel.org) обновление поддерживаемых веток Linux-ядра: 2.6.32.13 (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.13) и 2.6.33.4 (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33.4), в которых отмечено 99 и 118 исправлений. Наиболее заметные исправления затронули подсистемы: SCSI, libata, md/raid6, md/raid5, virtio, tun, sctp, ipv6, xfs, jfs, ocfs2, reiserfs, nfs, initramfs, ext4, USB, ath9k, r8169, ACPI, V4L/DVB, ALSA, drm/i915Отдельно можно отметить устранение в новых версиях ядра двух уязвимостей:
- Уязвимость (http://secunia.com/advisories/39316/) в реализации файловой системы ReiserFS, связанная с некорректной установкой прав доступа на директорию ".reiserfs_priv", что может быть использовано для получения повышенных привилегий.
- Уязвимость (http://security-tracker.debian.org/tracker/CVE-2010-1446) во встроенном отладчике KGDB, позволяющая получить доступ на запись ко всем областям памяти ядра.
URL: http://www.kernel.org
Новость: http://www.opennet.me/opennews/art.shtml?num=26579
> Уязвимость во встроенном отладчике KGDB, позволяющая
> получить доступ на запись ко всем областям памяти ядра.Это была фича!
А какие программы после этого пересанут работать?
Насчет ReiserFS... Эта уязвимоть была изначально? И если нет, то как долго? Ты не знаешь?
> А какие программы после этого пересанут работать?Это шутка юмора?
>Насчет ReiserFS... Эта уязвимость была изначально? И если нет, то как долго? Ты не знаешь?
В том виде как Рейзер сейчас, изменения были в 2.6.30.
Раньше этой дырявой функции не было, они была как часть кода другой.http://www.kernel.org/diff/diffview.cgi?file=%2Fpub...
А работал этот баг до 2.6.30 хрен знает, быстрее только проверить.
---
https://bugzilla.redhat.com/show_bug.cgi?id=568041#c0Steps to Reproduce:
As root:
truncate --size 64M test.reiserfs
mkreiserfs -f test.reiserfs
mkdir /mnt/test
mount -o loop,rw,user_xattr test.reiserfs /mnt/test
setfattr -n user.test -v myvalue /mnt/testAs an unprivileged user:
ls -l /mnt/test/.reiserfs_priv/xattrs/2.0
rm /mnt/test/.reiserfs_priv/xattrs/2.0/user.test # WhoopsActual results:
The unprivileged user can read and write to /mnt/test/.reiserfs_priv .Expected results:
All processes are denied access to /mnt/test/.reiserfs_priv .P.S.
ядро должно быть с CONFIG_REISERFS_FS_XATTR
Фича называлась KGB_DB :)
всегда думал так и должно быть, в солярисном mdb так и есть
Млин, это на PowerPC только
http://www.kernel.org/diff/diffview.cgi?file=%2Fpub...--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -155,15 +155,10 @@ static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
if (cur_cpu_spec->cpu_features & MMU_FTR_BIG_PHYS)
TLBCAM[index].MAS7 = (u64)phys >> 32;
-#ifndef CONFIG_KGDB /* want user access for breakpoints */
if (flags & _PAGE_USER) {
TLBCAM[index].MAS3 |= MAS3_UX | MAS3_UR;
TLBCAM[index].MAS3 |= ((flags & _PAGE_RW) ? MAS3_UW : 0);
}
-#else
- TLBCAM[index].MAS3 |= MAS3_UX | MAS3_UR;
- TLBCAM[index].MAS3 |= ((flags & _PAGE_RW) ? MAS3_UW : 0);
-#endif
tlbcam_addrs[index].start = virt;
tlbcam_addrs[index].limit = virt + size - 1;
ext4 до сих пор глючит? 1,5 года прошло. мы ей все уже пользуемся.
вы ей не пользуетесь, вы тестируете
Вот я ее тестирую, при том постепенно тестирование перешло в использование, как это и должно быть :-). Честное слово - крупных/опасных отвалов башки уже достаточно давно не замечается. ИМХО оно уже вполне годно для активного тестирования в боевых окружениях с последующим внедрежом. Учитывая разницу в скорости работы с EXT3 - перейти на ext4 весьма соблазнительно, мягко говоря.
в домашнем использовании большинcтво проблем не встретить.
Почему-то всегда вспоминается r4, при упоминании ext4. И становится немного досадно, честно говоря.
>sctpжалко стандарт в драфте, хотя
Cisco уже во всю юзает SCTP как решение для
подключения удаленных офисов с резервированием канала.
>жалко стандарт в драфте, хотя
>Cisco уже во всю юзает SCTP как решение для
>подключения удаленных офисов с резервированием канала.а можно детали?
Умудрился промахнуться случайно запущенным fsck по смонтированному ext4 разделу. Костей собрать так и не удалось :(
Почему собсно промахнулся - раз от разу на разделе появлялись ошибки, всё мирно лечилось. Потом ошибки перестали появляться, я заподозрил неладное...
Slackware 13 (2.6.29.6-smp)
> Slackware 13 (2.6.29.6-smp)Сами себе злобный баклан - я бы с EXT4 не стал меньше чем с .30 ядром связываться (исключительно по итогам смотрения ченжлогов). И то, лучше .32 - там фиксы всякие были. Кстат а разве fsck не вопит при потугах чекания смонтированного тома?
yes | fsck
:-)
>yes | fsck
>:-)Жостко =)
Кстати, предыдущему постеру я бы посоветовал проверить, а _почему_ ошибки вообще появляются?
Может железо полетело?
Ну например, виртуальные машины любят забанить ядро, спасает только SysRQ,
эксперименты с модулями ядра, тоже весело.
Из Юзерспейсных - только всякая х..ня на Жаве - Eclipse, Netbeans, Maple, Vuze,...----
А про EXT2/3/4 - ну не ставьте вы эту каку на ответственные системы.
XFS/JFS/Reiser3/4, для домашнего компа Reiser3 лучше нету!
У меня везде XFS, за последние 5 лет ни одного (тук-тук-тук) сбоя из-за ФС.
RAID5 на 8Тб спокойно из сети выдираю, если очень домой хочется, а ждать 20 минут,
пока оно потухнет, ломает.