Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Обновление sudo 1.9.17p2 с устранением ошибки, отправлявшей SIGHUP всем процессам"	+/–
Сообщение от opennews (??), 27-Июл-25, 08:07
Доступен новый выпуск утилиты sudo 1.9.17p2, используемой для организации выполнения команд от имени других пользователей. В новом выпуске устранена проблема, приводившая при определённом стечении обстоятельств к отправке сигнала SUGHUB (завершение работы) не запущенному процессу, а всем процессам в системе... Подробнее: https://www.opennet.me/opennews/art.shtml?num=63633
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 27-Июл-25, 08:07	–5 +/–
> без должного анализа возвращённого ранее кода ошибки Виноват си, потому что не дает sum types. То, что разраб забыл проверить -- простительно, потому что мозг -- это мясо. Мы не можем от мяса требовать 100%-ного анализа кода. К счастью, есть язык, который автоматизирует проверки. Он бы это выявил на этапе компиляции и подсказал мясу: "тут может вернуться ошибка". Мясо бы кивнуло и поблагодарило чудо-язык за техническую помощь.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #8, #18, #25

3. Сообщение от onanim (?), 27-Июл-25, 08:55	+5 +/–
а gcc разве не выдаёт такие варнинги при компиляции? и использование статических анализаторов разве не является обязательным при разработке критически важного софта?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #10, #11

5. Сообщение от Аноним (5), 27-Июл-25, 09:17	–2 +/–
killpg - это алиас для обычной остановки постгреса
Ответить | Правка | Наверх | Cообщить модератору

8. Сообщение от Anonimm (?), 27-Июл-25, 09:34	–4 +/–
А где же "миллионы глаз", которые пропустили эту ошибку ещё на этапе сборки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #12, #14, #37

10. Сообщение от Аноним (10), 27-Июл-25, 10:01	–6 +/–
Использование костылей разве не является обязательным при ходьбе?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

11. Сообщение от вымя (?), 27-Июл-25, 10:24	+8 +/–
Если вы откроете патч (https://github.com/sudo-project/sudo/commit/fb208d383af27a07...), то обнаружите, что pgrp приезжает из ec->cmnd_pid, который устанавливается вообще в другом месте, кем попало, как попало, аж в трёх си-файлах, да и там либо явно (= -1), либо очень косвенно (= cstat.val, = sudo_debug_fork()), а не из результата выполнения стандартной библиотечной функции. Компиляторный угадав тут явно бесполезен, потому что ему никто никогда не подскажет, используется ли потом это поле структуры в другом месте без проверки или просто авторы с привычками времён 80486 опять экономят байты исполняемого кода, удачно переиспользуя -1 по своему усмотрению. И, да, Result/Either type тут действительно сэкономил бы время всем, потому что компилятор бы гавкнул на попытку использовать этот тип как аргумент kill(), и сделал бы это быстро и надёжно, в отличие от статических анализаторов, которым нужно проверить миллион инвариантов среди сотен функций из десятков файлов, не запутаться в них и не вылететь по исчерпанию памяти. Если, конечно, какой-то анализатор вообще надоумили проверить, что в kill() передаётся -1 (в чём я сомневаюсь, потому что отрицательные аргументы у kill легитимны и используются гораздо чаще, чем может показаться), потому что анализировать коды возвратов тут, похоже, бесполезно (см. выше).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #36

12. Сообщение от нейм (?), 27-Июл-25, 10:28	+5 +/–
У семи нянек дитя с CVE
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

14. Сообщение от Аноним (14), 27-Июл-25, 11:57	+/–
у sudo настолько огромная кодовая база что отдельному программисту практически невозможно проверить все
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #15, #17, #34

15. Сообщение от Аноним (15), 27-Июл-25, 12:17    Скрыто ботом-модератором	+1 +/–
Переписать на Ржавом... и получится sudno.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

16. Сообщение от Карлос Сношайтилис (ok), 27-Июл-25, 12:31	+/–
> При передаче отрицательного значения группы поведение не определен Сишное мышление. Когда привык, что UB это неотъемлемая часть системы и переносишься это на уровень пользователя.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #39

17. Сообщение от Anonimm (?), 27-Июл-25, 13:29	–3 +/–
Тогда получается, что надёжность Linux - это просто слова?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #26, #28

18. Сообщение от Аноним (18), 27-Июл-25, 13:52	+/–
C не виноват в том, что люди не умеют докусентацию читать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #30

19. Сообщение от Аноним (18), 27-Июл-25, 13:55	–1 +/–
Ни когда не понимал, зачем такую косую утилиту пихают почти во все дистры линукса
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24

23. Сообщение от Аноним (25), 27-Июл-25, 14:52	+/–
>При передаче отрицательного значения группы поведение не определено Косяк killpg(). Они скажут, что тот кто использует killpg() должен контролировать что передает её. Но killpg() - часть системы, и приумножать хаос своей неопределенность не должна. Тем более проверка на входе для неё не критичная в плане производительности. Это все, может быть оставлено для костылей? Но ведь поведение кода не определено при таком фактическом значение!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27

24. Сообщение от Аноним (25), 27-Июл-25, 14:58	+/–
Потому что пользователей GUI пугают терминалы? ) Потому что он не в курсе привилегий и считает себя богом своей машинки, при этом ничего не понимая в плане безопасности надо принудительно разграничивать? )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

25. Сообщение от Аноним (25), 27-Июл-25, 15:01	+/–
> Виноват си, потому что не дает sum types в ядре это роскошь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #38

26. Сообщение от Аноним (26), 27-Июл-25, 15:14	+1 +/–
О 100% надёжности Linux никогда не говорили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #29

27. Сообщение от вымя (?), 27-Июл-25, 15:33	+/–
Описание в новости не имеет отношения к реальности, кстати. В патче не подчищают за killpg(), а меняют kill() на killpg(), а у kill() поведение при отрицательном pid как раз-таки определено чётко. Что, конечно, не отменяет ногострельности интерфейса в современных руках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

28. Сообщение от Аноним (28), 27-Июл-25, 15:56	+2 +/–
ваша аппаратная архитектура байдезинг ненадежна, о чем речь вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

29. Сообщение от Anonimm (?), 27-Июл-25, 15:57	–2 +/–
О, как! А как же "Linux работает на N компьютеров, входящих в топ-500"? Неужели обманули? 😆
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #31

30. Сообщение от Anonimm (?), 27-Июл-25, 15:59	–1 +/–
Ниче, скоро ИИ её читать будет, новости о новом бэкдоре станут чаще здесь мелькать..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

31. Сообщение от Нононим (?), 27-Июл-25, 16:01	+1 +/–
Работает. А надёжность то здесь причём?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #33

32. Сообщение от Anonimm (?), 27-Июл-25, 16:03	–3 +/–
Хороши "миллионы глаз", нечего сказать. Уязвимость случайно (?) появилась в сентябре прошлого года и только сейчас заметили, что sudo неправильно обрабатывает запросы.. Ниче, ИИ все эти "случайности" найдёт.. и добавит новые..
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35

33. Сообщение от Anonimm (?), 27-Июл-25, 16:05	–2 +/–
Так его пихают туда просто чтобы был? Да уж, умственные способности вендоров поражают.. 😆
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #47

34. Сообщение от 1 (??), 27-Июл-25, 16:43	+/–
Размер кодовой базы не причём. Налажал автор предыдущего изменения, а патч там был мелкий. В отладочном сообщении он прямо писал, что собирается вызвать killpg, но строчкой ниже вызывал kill. Если такие ошибки пропускают, значит с ревью изменений там на самом деле все плохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

35. Сообщение от 1 (??), 27-Июл-25, 16:52	+1 +/–
На линуксах баг не воспроизводится. Проблему обнаружили на AIX, когда до них доехала эта версия. То что она приехала к ним через год, для энтерпрайзов это нормально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #40, #41

36. Сообщение от 1 (??), 27-Июл-25, 17:10	–1 +/–
Они сейчас вставили проверку на -1. Ну ок, а если прилетит -2? С таким подходом ни какие расты не спасут. Их нельзя за это винить: Open Source отродясь был хобби для энтузиастов - где каждый волен галлюционировать как ему взимается. Проблему создали те, кто решил тащить создаваемый таким способом код в энтерпрайз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #42, #45

37. Сообщение от Аноним (37), 27-Июл-25, 20:04	–1 +/–
Я своими двумя посмотрел и снёс этот ваш sudo из системы. Чтобы пакеты не выпендривались, сделал псевдопакет без судо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

38. Сообщение от Аноним (37), 27-Июл-25, 20:08	+/–
В нормальном языке типы не утекают в исполняемый код. А если именно это и надо, то пилите struct с интом в начале структуры и всеми необходимыми структурами в union ниже. Великолепно работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

39. Сообщение от Аноним (37), 27-Июл-25, 20:12	+/–
Если я вашу rust программу (без шизофренической проверки каждого аргумента для каждой функции) запущу и на следующий день другой компонент системы, который вы в rust не контролируете (структура или код ошибки из ядра, данные из файла, из прилинкованной библиотеки), то в вашем расте внезапно тоже появится UB, потому что *ТЫ* не проверил входные данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #51, #52

40. Сообщение от вымя (?), 27-Июл-25, 20:39	+/–
Не «не воспроизводится», а «ещё не успели воспроизвести». Там же не только aix, но и огромная куча людей на сервере, например; давно вы такое видели на серверах? А /dev/pts у линукса тоже не резиновый, на секундочку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

41. Сообщение от Аноним (41), 27-Июл-25, 20:43	+/–
Когда портируют ПО из Linux в BSD, необходимо всё проверять, т.к. многие самые обычные вещи работают по-разному. Всегда проверяю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

42. Сообщение от Аноним (42), 27-Июл-25, 21:22	+1 +/–
> Open Source отродясь был хобби для энтузиастов - где каждый волен галлюционировать как ему взимается. Ты больной? Оупен сорс - это модель распространения исходников и не более, к качеству кода это вообще никак не относится. Или ты думаешь в закрытом софте как иначе пишут и не галлюцинируют? Достаточно венду вспомнить с её троянами, вымогателями и порнобаннерами
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #43

43. Сообщение от Аноним (43), 28-Июл-25, 08:24	+/–
Больной здесь скорее тот, кто докопался до формального лпределения. И да, в корпаниях пишут код иначе - там есть проверяющие. В опенсорсе же таких часто нет. И да, опенсорц это хобби, даже Линус когда ядро писал был студентом и это был его хобби проект. Без интереса корпораций линукс был бы сейчас в лучшем случае где-то среди бздей, а в худшем - хурдом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

44. Сообщение от Соль земли2 (?), 28-Июл-25, 10:19	+/–
Вот поэтому и существует Debian stable с проверенными временем пакетами.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #46, #49

45. Сообщение от laindono (ok), 28-Июл-25, 11:21	+1 +/–
А -2 это тоже валидное значение. Всё, что необходимо - сделать сильнотипизированную обёртку. Везде, где мы снаружи получаем какое-то значение, мы его парсим в тип. Примерно как фейсконтроль в баре. Проверяем, что мы получаем. Если это не, то, что ожидаемо в конкретном контексте - выводим ошибку. Чтонибудь вроде Result<ProcessId, i32> даже сойдёт. Окей, в некоторых местах будет Result<GroupId, i32>. Или enum { ProcessId(u32), GroupId(u32), ... }. И с другой стороны, когда нам надо вызвать kill, то мы прям перед этим проверяем, если в конкретном месте имеет смысл только pid, но не gid. Нам ведь надо превратить тип-сумму обратно в число. Просто делаем процесс явным всегда. Это сильно упрощает чтение кода, при том это самое чтение даёт больше информации. Более ёмкий и более читабельный код уменьшает вероятность логических ошибок. Поддержка становится проще и всё такое. А освободившееся время, которое не потрачено на пошаговый дебаг, можно использовать для написания тех же тестов например. Ведь не то, чтоб у нас были неограниченные ресурсы для написания и поддержки каждого мелкого винтика unix-way системы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

46. Сообщение от Anonimm (?), 28-Июл-25, 11:31	+/–
Вы же об этом https://www.linux.org.ru/news/linux-general/17448413 Debian Stable сейчас пишете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #48

47. Сообщение от Аноним (47), 28-Июл-25, 12:14	+/–
Значит, масштабируется на кластерах хорошо. Чтобы работал и задачи по моделированию ядерных взрывов крутил (Лос Аламос, Ливермор) вместо натурных испытаний, по моделилованию погоды (нужно всем странам).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

48. Сообщение от Соль земли2 (?), 28-Июл-25, 12:31	+/–
Тебе разрешаю на experimental сидеть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

49. Сообщение от Аноним (-), 28-Июл-25, 12:59	+/–
> Debian stable с проверенными временем дырявыми пакетами. Так будет точнее) У них минимум 3 года сквид был с 10+ штук уязвимостями. На который сам рахраю забил. Но удалять дыярый пакет это не по деби(ли)ановски)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #50

50. Сообщение от Соль земли2 (?), 28-Июл-25, 13:03	+/–
Может потому что squid надо самому всегда из исходников собирать, чтобы была поддержка HTTPS?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

51. Сообщение от Аноним (-), 28-Июл-25, 15:05	+/–
> в вашем расте внезапно тоже появится UB, потому что *ТЫ* не проверил входные данные. В худшем случае не UB, а паника. Если, допустим, у меня есть тип ProcessId, и я не проверил входные данные, прежде чем делать ProcessId::from_int(pid), то ProcessId::from_int выкинет панику. Либо, альтернативный подход к этому -- не паника, а Result<ProcessId,Error> возвращаемый из from_int. В этом случае, раст заставит обработать ошибку, то есть входные данные будут проверены и ошибка будет обработана. > без шизофренической проверки каждого аргумента для каждой функции Раст больше заточен на проверку возвращаемых значений. Аргументы проверять нет нужды, потому что их свойства гарантируются по-построению. Нет смысла проверять &str на utf8-валидность, потому что &str по построению валиден. Проверки аргументов тоже бывают, тот же index проверяет входной аргумент usize, но вот это как раз скорее отход от Rust-way.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

52. Сообщение от Аноним (52), 28-Июл-25, 17:01	+/–
В Расте обычно не проверки аргументов из примитивных типов, а предварительное преобразование из примитивных в оберточные типы. Проверка делается в конструкторе. Без проверок никуда, но с таким подходом их будет намного меньше (если это pid, то мы знаем, что он не может быть -1, и пишем это один раз), а аргументом принимаем уже тип pid, который по определению (если мы правильно написали его конструктор из инта) валиден. Такой подход, можно сказать, заставляет написать все проверки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема