Qt 5.3 портирован для Haiku OS

Ответ на: комментарий от multihead 22.07.14 11:03:14 MSK

В гайке асинхронное микроядро - это безусловно правильные вещи, но пришлось жертвовать защитой требуемой во многопользовательских системах.

При чём тут микроядро и защита? Многопользователя нет, потому что его никто не писал. А не писал потому что некому, некогда и влом. «Пришлось жертвовать защитой» не более чем слону крыльями и совершенно без связи с архитектурой ядра.

Eugenep
(22.07.14 11:59:46 MSK)

Qt 5.3 портирован для Haiku OS

Этим шагом они хотят выгнать с Haiku обоих последних юзеров?

Lavos ★★★★★
(22.07.14 12:06:20 MSK)

Ссылка

Ответ на: комментарий от Eugenep 22.07.14 11:59:46 MSK

Многопользователя нет, потому что его никто не писал. А не писал потому что некому, некогда и влом. «Пришлось жертвовать защитой» не более чем слону крыльями и совершенно без связи с архитектурой ядра.

На самом деле мультиюзерность в гайке есть, просто по умолчанию отключена за ненадобностью. (Пруф - http://cgit.haiku-os.org/haiku/tree/configure#n57 )

Все coreutils, файловая система bfs, рабочий стол поддерживают расстановку posix-прав.

threedeyes
(22.07.14 12:08:22 MSK)

Ответ на: комментарий от threedeyes 22.07.14 12:08:22 MSK

На самом деле мультиюзерность в гайке есть

А то я не знаю :) Просто любой юзер себе любые права выставить может :) И хомяков нет.

Eugenep
(22.07.14 12:20:09 MSK)

Ссылка

Ответ на: комментарий от multihead 22.07.14 11:03:14 MSK

Идеального ядра пока нет.

Про идеал в чём-либо забудьте, такого просто не бывает в природе.

В гайке асинхронное микроядро..., но пришлось жертвовать защитой требуемой во многопользовательских системах.

А как связаны асинхронность с «многопользовательскостью»?

Говоря по чести, я сомневаюсь, что она особенно нужна. Для десктопной-то системы.

Также неизвестно как ведёт себя асинхронность при большом количестве процов.

Нормально ведёт. В Сети есть статьи по теме.

Хорошее однопользовательское ядро для рабочей станции.

Deleted
(22.07.14 12:52:01 MSK)
Последнее исправление: rht 22.07.14 12:52:37 MSK (всего исправлений: 1)

Ответ на: комментарий от EXL 21.07.14 22:26:08 MSK

Господи, это же местный тролль-дурачок.

Да виндозоидов тут до черта и псевдолинуксоидов не любящих RMS то-же. Уродцы.

quest ★★★★
(22.07.14 14:22:40 MSK)

Ссылка

Ну хоть где-то Qt смотрится лучше, чем в KDE.

~~cmbbrkr~~ ★
(22.07.14 15:15:31 MSK)

Ссылка

Ответ на: комментарий от korvin_ 22.07.14 11:45:02 MSK

пространства имен

Собственно например:

#include <u.h>
#include <libc.h>

#define DATA "hello\n"
#define LS   "/bin/ls"
#define FOO  "/data/foo"
#define ROOT "/"

void ferr(char*, char*);

void
main(void)
{
	int i, n, ls, foo, root;

	rfork(RFNAMEG);          // copy parent's namespace
	bind(".", "/", MREPL);

	ls = open(LS, OREAD);
	if (ls < 0)
		ferr("open", LS);
	else
		close(ls);

	foo = create(FOO, OWRITE, 0666);
	if (foo < 0)
		ferr("create", FOO);
	else {
		write(foo, DATA, strlen(DATA));
		close(foo);
	}

	root = open(ROOT, OREAD);
	if (root < 0)
		ferr("open", ROOT);
	else {
		n = dirreadall(root, &dirs);
		for (i=0; i<n; i++)
			print("%s%s\n", ROOT, (dirs+i)->name);
		free(dirs);
		close(root);
	}

	exits(nil);
}

void
ferr(char *action, char *file)
{
	fprint(2, "can't %s %s: %r\n", action, file);
}

term% pwd
/usr/glenda/src/cmd
term% ls
data
mkfile
nsex.c
term% ls data
term% mk nsex
	8c -FTVw nsex.c
	8l $LDFLAGS -o nsex nsex.8
term% ./nsex
can't open /bin/ls: '/bin' file does not exist
/data
/mkfile
/nsex
/nsex.8
/nsex.c
term% ls data
data/foo
term% cat data/foo
hello
term%

korvin_ ★★★★★
(22.07.14 15:23:24 MSK)

Ответ на: комментарий от A-234 22.07.14 10:32:02 MSK

И как редактору догадаться в каком месте себе руки отрубать?

в командной строке (в аргументах к программе) указать ключ --unsafe ? :-)

user_id_68054 ★★★★★
(22.07.14 17:22:36 MSK)

Ответ на: комментарий от korvin_ 22.07.14 15:23:24 MSK

признаюсь честно — мне сложно понять почему произошло в программе can't open /bin/ls: '/bin' file does not exist

и как работают операции rfork(RFNAMEG); bind(".", "/", MREPL);

но я ощущаю что похоже — да — программа сама себя лишила доступа к чему-то :)

user_id_68054 ★★★★★
(22.07.14 19:02:30 MSK)

Ответ на: комментарий от user_id_68054 22.07.14 19:02:30 MSK

мне сложно понять почему произошло в программе

Потому что я заменил корневой каталог в пространстве имен процесса программы на текущий каталог (откуда программа была запущена), а там никакого /bin/ls нет.

и как работают операции

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

bind собственно монтирует один каталог в другой, почти как mount -bind в линуксе. В данном случае текущий каталог монтируется в корень, перекрывая все что есть в корне.

Т.е. грубо говоря это что-то вроде chroot.

korvin_ ★★★★★
(22.07.14 19:26:52 MSK)

Ответ на: комментарий от korvin_ 22.07.14 19:26:52 MSK

bind собственно монтирует один каталог в другой, почти как mount -bind в линуксе.

а сам процесс уже потом не способен отменить эту операцию? (только в одну сторону?)

если да — то это наверное хорошо..

user_id_68054 ★★★★★
(22.07.14 20:13:21 MSK)

Ответ на: комментарий от user_id_68054 22.07.14 20:13:21 MSK

а сам процесс уже потом не способен отменить эту операцию? (только в одну сторону?)

Ну вообще-то unmount. Хотя конкретно в данном случае (замена корня) будут некоторые проблемы.

если да — то это наверное хорошо..

Что хорошего?

korvin_ ★★★★★
(22.07.14 20:20:37 MSK)

Ответ на: комментарий от korvin_ 22.07.14 20:20:37 MSK

Что хорошего?

можно было бы применять для целей безопасности (если бы процесс не мог бы отменить это сам).

но так как операция подлежит отмене — то думаю безопасности это не добавляет :) ..

это как я отдам денег жене и скажу ей: "дорагая, вот моя заначка.. я даю эти деньги тебе на сохранение, и если я у тебя их попрошу до начала отпуска — не давай мне ни в коем случае!"

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

как-то примерно так :-)

user_id_68054 ★★★★★
(22.07.14 20:30:41 MSK)

Ответ на: комментарий от user_id_68054 22.07.14 17:22:36 MSK

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

A-234 ★★★★★
(22.07.14 20:34:04 MSK)

Ссылка

Ответ на: комментарий от user_id_68054 22.07.14 20:30:41 MSK

можно было бы применять для целей безопасности (если бы процесс не мог бы отменить это сам).

Но он может просто не вызывать bind. И?

но так как операция подлежит отмене — то думаю безопасности это не добавляет :)

О какой вообще безопасности речь, если ты предлагаешь, чтобы программа сама просила что-то ей запретить? Кто ей мешает не просить?

это как я отдам денег жене и скажу ей
...
а завтра я вдруг приду пьяный с работы домой и скажу жене

Нет, в твоей идее нет никакой жены, ты предлагаешь просто класть деньги в тумбочку.

korvin_ ★★★★★
(22.07.14 20:40:40 MSK)

Ответ на: комментарий от korvin_ 22.07.14 20:40:40 MSK

О какой вообще безопасности речь, если ты предлагаешь, чтобы программа *сама_просила* что-то ей запретить? Кто ей мешает не просить?

если программа не будет просить убрать с себя лишнии привилегии — то такое разумеется возможно..

..это просто было бы равносильно багу безопасности (в конкретной программе).

исправлять или не исправлять подобный баг безопасности — разумеется это личное дело разработчиков программы.

но думаю люди сочли бы такое поведение «слегка» подозрительным, в ситуации когда 99% остальных программ всё-таки будут снимать с себя лишнии привилегии. :-)

вот сегодня, например в linux-kernel то и дело встречаются баги из разряда «повышение полномочий».

и эти linux-kernel баги быстренько исправляют, ведь ни кому в голову из разработчиков ядра НЕ приходит сказать "ды, вы что, ребята! это же не баг! повышение полномочий возможно только когда злоумышленник *уже* выполняет свой исполняемый код на влзамываемом компьютере"

в твоей идее нет никакой жены, ты предлагаешь просто класть деньги в тумбочку.

жена там это там как аналогия API ядра. :)

в тумбочку можно класть деньги и обратно оттуда брать тоже можно. а вот если дать денег жене — то обратно она ни чего уже не отдаст (если конечно в жене нет неисправленных уязвимостей :))..

деньги — аналогия ресурсов. (хотя слегка кривоватая аналогия:)).

пьяный — аналогия взломанный и не отвчающий за свои слова.

user_id_68054 ★★★★★
(22.07.14 20:53:46 MSK)
Последнее исправление: user_id_68054 22.07.14 20:56:43 MSK (всего исправлений: 2)

Ответ на: комментарий от user_id_68054 22.07.14 20:53:46 MSK

Не надо городить огород и заставлять разработчиков всех программ встраивать в них какие-то дополнительные функции, это не портабельно, не универсально и не KISS'ово. Да и не безопасно. Это должно делаться внешне — chroot, песочницы и тому подобное.

korvin_ ★★★★★
(22.07.14 21:04:33 MSK)

Ссылка

Ответ на: комментарий от user_id_68054 22.07.14 00:35:51 MSK

но в остальном у трояна сейчас на linux полная свобода и без необходимости всякого root

Капитан намекает, что предлагаемые тобой вещи этого никак не изменят. Значит нинужно.

anonymous
(22.07.14 21:10:23 MSK)

Ответ на: комментарий от anonymous 22.07.14 21:10:23 MSK

Значит нинужно.

ды я бы и не сказал что то что я предлагаю — это якобы прям нужно.. нееееет :)

просто я считаю что однопользовательская система была бы чуть-более логичнее чем то что есть сейчас.. вот и всё :-)

ну или если нет (нет пути этому) то значит нет, время рассудит как всё будет развиваться на самом деле.

а я предсказываю что linux в итоге так и будет развиваться по направлению к однопользовательности. медленными елезаметными эволюциями.

количество всевозможных API для разного рода «песочниц» — в linux будет рости. а вот использования разграничений на пользователи для безопасности будет падать.

будут появляться\развиваться всякие-разные policykit и logind, ..

быть может в конечном итоге — вообще в linux станет только два пользователя root и non-root :).. ну или 3 (root, user, service)..

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

user_id_68054 ★★★★★
(22.07.14 21:29:48 MSK)

Ссылка

Ответ на: комментарий от Eugenep 22.07.14 11:59:46 MSK

При чём тут микроядро и защита? Многопользователя нет, потому что его никто не писал. А не писал потому что некому, некогда и влом. «Пришлось жертвовать защитой» не более чем слону крыльями и совершенно без связи с архитектурой ядра.

https://ru.wikipedia.org/wiki/GNU_Mach#.D0.9F.D1.80.D0.BE.D0.B1.D0.BB.D0.B5.D...

Связь микроядерной архитектуры, скорости работы микроядра и защищённости есть! И в этом основная сложность их проектирования. Если брать модель безопасности Unix, то её реализация в микроядре (известными мат моделями) делает его не конкурентно способным по скорости с монолитными ядрами.

В если модель безопасности не Юникс (её перенесли с ядра в пользовательский режим), скорость БЕЗ БЕЗОПАСНОСТИ будет заметно лучше:

https://ru.wikipedia.org/wiki/L4_(микроядро)

https://ru.wikipedia.org/wiki/GNU_Mach#.D0.A1.D0.BB.D0.B5.D0.B4.D1.83.D1.8E.D...

Меня сейчас опять обозвут «жирным и зелёным», но я уверен что существует дешовая и безопасная модель микроядра...

В гайке нет многопользовательского режима потому что человечество до сих пор не знает как написать быстрое и безопасное микроядро!

;)

multihead
(23.07.14 10:15:50 MSK)