Как "перезапустить терминал"

Набрать reset в слепую и нажать энтер.
После сказать echo -ne "\033(K" для переключения кодовой страницы на
пользовательскую.

Убивать agetty не надо, достаточно убить зависшее приложение. Если работал
с консолью, то, скорее всего это bash.
Для этого сказать в другой консоли ps -ax, посмотреть pid процесса на зависшей
консоли и сказать kill -9 <pid>.

On Fri, 17 Oct 2003, d2r wrote:

IMHO можно убить и getty, если не ясно, какой именно прцесс завис.
Потомки тоже убьются автоматически. Убивание login - то же самое
но на уровень ниже. Я правильно понимаю?

Если работал

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Поставил себе Red Hat 9.0. На том компьютере, где производилась
установка, все работает нормально, но когда я подключаю жесткий диск к
своему старому комьпьютеру (486, 20Mb) Linux не грузится. После выбора
системы в загрузчике появляется надпись
Loading Linux .............
и компьютер просто перезагружается. Использовал LILO, GRUB и LoadLin -
везде одно и то же. Недавно проделывал ту же операцию с ASP Linux -
там все грузилось нормально.
Подскажите, пожалуйста в чем тут дело.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

В сообщении от 21 Октябрь 2003 15:57 Андрей Шуманский написал:

Могу предположить, что пакеты RH9.0 скомпилированы для процессоров i586.
Соответственно, они будут работать только на i586 и выше. Но при установке
наверняка можно отключить опцию типа "устанавливать оптимизированные версии
пакетов".

On Tuesday 21 October 2003 13:57, Андрей Шуманский <Андрей
Шуманский <shumans***@t*****.by>> wrote:

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

Я сейчас посмотрел в дистрибутив - там готовых ядер для
архитектур i386/i486 нет вообще. Так что надо пересобирать.

Ещё надо убедиться, что glibc установлена для i386 (такая в
дистрибутиве есть)

--
Serge B. Khvatov Phone:+7(812)1133186 //
+7(812)1106579 //echno
mailto:xbat***@t*****.ru // St-Petersburg

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

У меня такая-же проблема на P-200 mmx. Ни одно ядро, даже самосборное,
оптимизированное под i568 у меня не пошло (такая-же картина -
загрузка..перезагрузка). Подозреваю, что проблема или в камне или в мамке.
Короче, в моем железе.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Приветствую.

При попытке установить соединение с провайдером из-под нерутового логина
получаю в /var/log/messages следующее:

Oct 21 20:27:32 noname chat[4096]: send (fitec^M)
Oct 21 20:27:32 noname chat[4096]: expect (word:)
Oct 21 20:27:32 noname chat[4096]: fitec^M
Oct 21 20:27:32 noname chat[4096]: Password: -- got it
Oct 21 20:27:32 noname chat[4096]: send (********)
Oct 21 20:27:32 noname pppd[4092]: Serial connection established.
Oct 21 20:27:32 noname chat[4096]: timeout set to 10 seconds
Oct 21 20:27:33 noname pppd[4092]: ioctl(PPPIOCGUNIT): Operation not permitted
Oct 21 20:27:33 noname pppd[4092]: ioctl(PPPIOCGDEBUG): Operation not permitted
Oct 21 20:27:33 noname pppd[4092]: Exit.

Естественно ничего не получается. Как решить проблему?

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

On Tuesday 21 October 2003 23:35, Alexander S. Yurkov wrote:

[...]

А suid у pppd установлен?

On Tue, 21 Oct 2003, george wrote:

Терминоогию знаю плохо. так что лучше из'ясняться на естественном языке.
Естественно "владелец" pppd - root. Остальным разрешается его только
исполнять. Я не хочу чтобы пользователи могли делать с pppd что-либо,
кроме его запуска. Как видно из приведенного куска лога
pppd успешно начинает исполняться. Даже соединение проходит. А потом
'not permitted'...:-(

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Как выясняется, у файла 12 бит атрибутов. 9 из них - полностью понятно,
это права доступа (писать/читать/запускать) для владельца, группы и
остальных. Еще один был бы тоже понятен, запускать программу как
программу владельца файла или програму пользователя, вызвавшего файл на
исполнение. В конце-концов это мог бы быть бит PSW, определяющий в каком
режиме процессора передается управление на програму - ядра или
пользователя (в зависимоти от привелегрованный пользователь/владелец_файла
или нет). Но три бита - не понятно. Какой бы мог быть смысл в бите
group ID? Зачем (!!!) это? И зачем сохранять текст (надо думать - код
програмы) на swap device? Это уже потом, когда ОЗУ не хватит... Какая-то
сложная логика свопинга?

Ради Бога, не надо ничего про синтаксис каких-либо команд, только логику
зачем (!!!) нужно эти три бита управления. На что они влияют. Без
специфических для *nix терминов. Если кто пришлет это мне в приват в виде
некого документа, который можно почитать (все равно на русском или
английском) буду признателен, http доступа нет. Но не более 0.5 Мбайт!
В HOWTO и man не нашел ничего, да и вообще там все на "рецептурном
уровне" :-( "Рецепты" на интересны, интересны концептуальные соображения.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Hi Alexander S. Yurkov!!!

Wednesday, October 22, 2003, 5:30:21 AM, you wrote:

Вот ваши три бита:

S_ISUID 04000 set user ID on execution
S_ISGID 02000 set group ID on execution
S_ISVTX 01000 sticky bit

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

цитата из книжки:

"The next obvious step was to stop some of that extra disk-to-disk copying at
start-up time. Programs that were run frequently═- such as cc, ed, and rogue═-
could share the same program pages. Furthermore, even if no copy was currently
running, we could expect another one to be run soon. Therefore, keeping the
pages in memory and on the swap partition, even while we weren't using them,
made sense. The "sticky bit" was added to mark those programs as worth
saving. Since those times, larger memories and better memory management
methods have largely removed the original need for the sticky bit."

From Russia with love
mailto:serge***@o*****.ru

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Alexander S. Yurkov пишет:

Идея в том, что пользователь запустивший программу на которой установлен
бит SUID получает все права ее владельца, иногда это нужно. Правда
возникают и траблы с безопастностью...
Например дать скрипту делать свою работу для пользователей определенной
группы.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Здравствуйте, Alexander.

Вы писали 22 Октябрь 2003 г., 4:30:21:

Пару цитат:
man chmod
STICKY FILES
On older Unix systems, the sticky bit caused executable files to be
hoarded in swap space. This feature is not useful on modern VM sys-
tems, and the Linux kernel ignores the sticky bit on files. Other ker-
nels may use the sticky bit on files for system-defined purposes. On
some systems, only the superuser can set the sticky bit on files.

STICKY DIRECTORIES
When the sticky bit is set on a directory, files in that directory may
be unlinked or renamed only by root or their owner. Without the sticky
bit, anyone able to write to the directory can delete or rename files.
The sticky bit is commonly found on directories, such as /tmp, that are
world-writable.
man 2 stat
The set GID bit (S_ISGID) has several special uses: For a directory it
indicates that BSD semantics is to be used for that directory: files
created there inherit their group ID from the directory, not from the
effective gid of the creating process, and directories created there
will also get the S_ISGID bit set. For a file that does not have the
group execution bit (S_IXGRP) set, it indicates mandatory file/record
locking.

The `sticky' bit (S_ISVTX) on a directory means that a file in that
directory can be renamed or deleted only by the owner of the file, by
the owner of the directory, and by root.
Смысл тот что эти три бита позволяют организовать доступ к файлам
группе пользователей более гибким способом (включая управление
доступом для процессов соотвествующих этим исполняемым файлам), не
используя при этом более сложные методы вроде ACL.

P.S.: одно из преимуществ Free Unix-like systems это, как правило, стандартно
поставляемая отличная документация.

Приветствую.

On Tue, 21 Oct 2003, Vasile wrote:

Спасибо.

Хм-м-м... У меня этого в ман нет. Ну ей-богу нет, синтаксис команд и
все... Может потому, что система древняя (Caldera 96 года)? Или может я
что недоустановил? Дискового пространства в обрез (всего 500М),
приходится экономить...:-(

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Здравствуйте, Alexander.

Вы писали 22 Октябрь 2003 г., 13:01:17:

Возможно, что причина в древности системы. Хочу обрать ваше
внимание на тот факт что существует несколько разделов man -
1..8,n; каждый раздел содержит страницы определёной направлености
(1 - комманды пользователя, 2 - системные вызовы, 3 - библиотечные
функции, ... 8 - системные (административные) комманды).
При простом вызове man chmod откроется первая доступная chmod
страница, то есть man 1 chmod (man man :). поэтому бльше
информации по подобной теме можно найти использовав явное
указание раздела (к примеру: man 2 chmod). Само собой поиск по
ключевым словам даст ещё больше результататов
(man -k ключевое_слово).

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

On Tue, 21 Oct 2003, Vasile wrote:

Пока не понял на счет GUID (остальное более-менее). В части управления
правами доступа для процессов. А вообще сколько подразумевается
возможных режимов процессора? Ясно, что в простейшем случае может быть два
- пользователя и ядра. Но может подразумевается больше? Хотя и не понятно
зачем... Или на режим процессора при исполнении файла может влиять только
SUID?

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

В сообщении от 22 Октябрь 2003 16:34 Alexander S. Yurkov написал(a):

Имеет место быть недоразумение. Режимы _процессора_ здесь абсолютно не при
чем. Ядро всегда работает в privileged, все остальное всегда в user mode.
Режимы доступа определяются для _процесса_.

Здравствуйте, Alexander.

Вы писали 22 Октябрь 2003 г., 13:34:08:

Забудем о режимах процессора: о привилигерованном режиме CPU имеет
смысл говорить только относительно программного кода в ядре (включая
и динамически подгружаемые модули). Конечно только имея права root
можно вызываять некоторые системные функции несвязаные с апаратурой
(chroot, к примеру) или же связаные (некоторые ioctl() вызовы для
устройств), но всё равно это может реализоваться даже не имея
апаратной поддержки для разделения уровня привилегий подобной x86-32
(i386+), поэтому будем считать что root это повышенные привелегии в
рамках OS.
Теперь "на счёт GUID", а точнее SGID (Set Group Identifier) бита.
При использовании этого бита на каталоги, все созданные в нём файлы
будут иметь GID равный GID каталога, а не процесса его создающего.
Пример: каталог для проектов /home/prj, в группу prj входит
пользователь progr_cool, имеющий основную группу progr_cool
(нормальная ситуация в RedHat-like дистрибутивах) при umask=007 (то
есть созданные файлы будут иметь mode=mode & ~umask, то есть другие
пользователи не будут иметь никаких прав на этот файл), тогда при
установленом SGID на /home/prj созданный файл будет иметь параметры
UID=progr_cool, GID=prj, mode=0nn0 (на пример 0660)
иначе
UID=progr_cool, GID=progr_cool, mode=0nn0
и в этом случае любой другой програмист входящий в группу prj ничего
не сможет сделать с файлом.
Теперь о использовании SGID для файлов. Опять пример (надеюсь
более менее понятный): есть устройство /dev/dri/card0 с правами
UID=root, GID=dri, mode=660 (rw-rw---), и игры использующии
hardware 3D (DRI) - quake3 с правами UID=root, GID=dri, mode=2755
wolf с правами UID=root, GID=dri, mode=0755 (без SGID)
В первом случае любой запустив quake3 получит 3D (quake3 изменит
свой EGID=dri, и сможет работать с /dev/dri/card0), а запустив
wolf - получит ошибку (в более простой игре - отсутсвие
Hardware3D), так как элементарно не хватает прав.
Пара замечаний: 1. заметили SUID не установлен и root'a никто не
получает!
2. В любом из этих примеров не расматривается
случай когда пользователем является root'ом
(по понятным всем причинам)
3. Я упомянул EGID (Efective GID), на самом деле
у любого процесса есть четыре идентификатора:
real UID, real GID, Efective UID, Efective GID.
real'ьные ID - это ID пользователя вызывавшего
процесс. Efective ID - изначально равны своим
real аналогам, но могут быть изменены (устоновкой
SGID/SUID, или вызвав
setuid(), setgid(),
seteuid(), setreuid(),
setegid(), setregid())

Приветствую.

On Wed, 22 Oct 2003, Vasile wrote:

Большое спасибо. Это очень интересно для меня. Что-либо про
компьютеры я изучал лишь в то далекое время, когда ни персоналок, ни
юникса (на имеющихся в нашей стране машинах) и в помине не было.
На сколько я помню, тогда все защиты делались через режим процессора.
Но я не могу понять, как в принципе можно сделать защиту не используя
режимы процессора (в рамках ОС, как Вы говорите). Если все команды
процессора доступны, и доступны все области адресного пространства
(в т.ч. все апаратные регистры) то можно написать програму, которая
взломает любые прграмные (в рамках ОС) привелегии. Во всяком случае на
ассемблере. Или я не прав?

Прошу прощения если кому-либо это кажется банальностью.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Alexander S. Yurkov пишет:

Вы правы. Разделение прав между ОС и программами и защита ОС делается и
сейчас режимами процессора. Насколько я понял Vasile он говорил об
ограничении
прав пользователей (от имени которых и выполняются процессы), и
соответсвенно
ограничении прав программ. Все программы кроме ядра работают на x86
процессорах
в кольце 3 - т.е. с наименьшими привилегиями, даже запускаемые root'ом.
В кольцо 0
(режим ядра) код можно запихнуть только если root загрузит
соответсвующий модуль ядра.
Защиты с помощью режимов процессора, защиты памяти недостаточно для
реализации,
например, разграничения доступа к файлам.

Приветствую.
Думаю такая тема будет точнее отражать суть (теперь уже).

On Wed, 22 Oct 2003, Max Vasin wrote:

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

Но возникает следующий вопрос. Откуда знает обработчик системного вызова
какой процесс его вызвал. Если передавать ему адрес заголовка процесса
из вызывающего процесса, то это "дыра" через которую защиту можно сломать.
Можно, конечно, достать со стека адрес возврата а потом найти какому
процессу соответствует этот адрес, но это так долго!

И еще один вопрос. Наверное должен быть какой-то простой и общий алгоритм,
по которому по Effective/Real [U/G]ID вызывающего процесса и [U/G]ID
требуемого ресурса определяется нарушены ли права. Естественно считать,
что нарушение прав если (EUID<UID) OR (EGID<GID). Но по примеру,
приведенному Vasile, это не так. А как???

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Alexander S. Yurkov пишет:

Сразу замечу: я не специалиист по защищенному режиму x86 процессоров, но
немножко знаю :) Насколько я понимаю процессор при возникновении прерывания
(а в Linux именно ими делаются системные вызовы, хотя можно делать
межстраничные
вызовы функций с переключением контекста, AFAIK) процессор сохраняет
текущий
контекст в какой-то своей структуре, по которой обработчик и определяет
информацию
о процессе. Это в общих словах. Вообще надо читать Intel Architecture
Software Developer's
Manual Volume 3, там описаны особенности реализации ОС на интеловских
процессорах
(сам читал только несколько кусочков по организации и управлению
памятью). С другой
стороны читал, что системные вызов выполняется в контексте текущем
процессе, т.е.
структры, описывающие процесс, ни откуда извлекать не надо.

Хороший вопрос :) Т.к. часть вызовов может выполнять только root, то для
них эта
проверка, скорее всего, реализуется простым сравнением EUID == 0.
Сложнее с проверкой
прав доступа к файлам, ведь пользователь может состоять в нескольких
группах, но в этом
случае проверка выполняется только при открытии файла, поэтому можно
допустить и простую
итеративную (по группам) проверку прав.

Приветствую.

On Wed, 22 Oct 2003, Max Vasin wrote:

IMHO в данном случае, речь идет о контексте процессора. Т.е. о его
регистрах (в т.ч. PSW и регистры управления памятью) и все. Это не то же
самое, что контекст процесса. И нечего толком из такого контекста о
процессе извлечь нельзя. Кроме адреса возврата, PSW и регистров
управления памятью.

Потом UNIX на каких только машинах не реализовывалась. Не думаю чтобы эти
вопросы на разных процессорах решались так уж по разному. Начинался UNIX
на PDP-7 (или 8?) и уж во всяком случае был на PDP-11. Как работала
команда синхронного прерывания (системный вызов это она и есть) на
PDP-11 я знаю достаточно хорошо. В стеке сохранялся програмный счетчик
и PSW вот и все. Вот и весь контекст. Ну и что в регистрах общего
назначения осталось тоже передавалось, естественно.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Здравсвуйте, господа.

Вопрос: где в сети можно найти хорошую доку по этому вопросу?

Леший.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

On Wed, 22 Oct 2003, Max Vasin wrote:

Не думаю что можно применить межстраничные вызовы функций. Суть простая.
При системном вызове процессор должен перейти из режима пользователя
в режим ядра. Если при этом не будет фиксирован адрес передачи управления
(синхронное прерывание и отличается тем, что этот адрес фиксирован),
то легко будет можно пользователю сменить режим на режим ядра. Продолжая
при этом управлять процессором. Так что от защиты ничего не останется.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Здравствуйте, Alexander.

Вы писали 23 Октябрь 2003 г., 0:45:54:

Не возвражаю. Хотя можно было оставить и file attributes

To: Max Vasin
да, я с Вами полностью согласен.

Защита несколько сложнее и включает себя использование MMU. В случае
его отсутсвия возникают проблемы реализации Linux (ядра). Однако часть
таких ограниченных архитектур всё-же обзаводится MMU (Etrax100 ->
Etrax100LX), а с другой стороны подержка остальных MMU-less систем
добавляется в uLinux и Linux 2.6.

отношения больше/меньше здесь не верны (используются знаки равно/не равно).
Для опреедленя прав проверяются права слева на право (то есть User,
потом Group, и наконец Others); для сверки используется Efective
{U,G}ID и {U,G}ID файла (а в общем случае (semaphores, message queue,
shared memory) - ресурса).

On Wed, 22 Oct 2003, Vasile wrote:

Т.е. условие того, что привелегии не нарушены такое:

(EUID=UID) AND (EGID=GID)

Почему же тогда в Вашем примере с двумя играми 'рута никто не получает'
но при этом одна из игр получает доступ к ресурсу с UID=root?

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Здравствуйте, Alexander.

Вы писали 23 Октябрь 2003 г., 14:05:39:

Всё просто, хотя у ресурса UID=root, но GID=dri, и процесс исполняющий quake3
( с правами UID=root, GID=dri, mode=2755) имея бит SGID изменяет свой EGID
до dri
(хотя у пользователя GID мог быть, скажем, local_users_group). А к
файлу /dev/dri/card0 группа dri имеет доступ как на запись так и
чтение.
Этот пример как раз про использование GID/SGID.
И не в root'e дело :-)

Приветствую.

Вернемся к привелегиям.

On Thu, 23 Oct 2003, Vasile wrote:

Ах процесс с UID=root...

На счет {Real,Effective}{G,U}ID и S{U,G}ID вроде все понятно.

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

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Alexander S. Yurkov пишет:

Для root'а проверка прав просто пропускается, что-то типа
!UID && (<проверка-прав>)
т.к. UID root'а равен 0, всегда.

Здравствуйте, Alexander.

Вы писали 23 Октябрь 2003 г., 22:22:37:

Нет, файл quake3 с правами UID=root, GID=dri, mode=2755.
А процесс имел изначально EUID=john EGID=john (john - как пример
обычного пользователя); после вызова (с учётом SGID)
execve("/usr/local/games/quake3/quake3", argvp, envp)
процесс будет иметь EUID=john, EGID=dri, RUID=john, RGID=john.

Приветствую.

On Thu, 23 Oct 2003, Vasile wrote:

quake3

Ну так тогда получается противоречие. Вы же говорили что по равенству
проверяются привелегии. У процесса EUID=john у ресурса UID=root. Хотя
EGID=GID не должно быть доступа если по равенству...

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Alexander S. Yurkov пишет:

Почему? Смотря какие права на доступ для группы...

On Fri, 24 Oct 2003, Max Vasin wrote:

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

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Здравствуйте, Alexander.

Вы писали 24 Октябрь 2003 г., 12:22:18:

Продолжу пример:
1. У процесса EUID=john, у ресурса UID=root, неравенство ==> шаг 2
(если равенство то процесс получил бы права "rw-" согласно mode
файла /dev/dri/card0)
2. У процесса EGID=dri, у ресурса GID=dri, равенство ==> получаем
права "rw-" (см. mode=660 для /dev/dri/card0) - всё отлично
работает
(если неравенство ==> шаг 3)
(3. Для OTHERS в данном случае(mode=660) права "---", то есть нулевые )

On Wed, 22 Oct 2003, Vasile wrote:

Понятно. Действительно полезный в некоторых случаях механизм.

Почему же тогда возникают права на доступ к устройству?

Собственно тут надо понять как из [U/G]ID файла и пользователя,
запустившего файл, получаются [Real/Effective] [U/G]ID (это вроде понятно:
Real [U/G]ID := [U/G]ID пользователя, Effective ... := ... файла если
установлен соотв. бит S[U/G]ID иначе ... пользователя, так?) и как и
где ...ID процесса дальше использются (это уже непонятно). По сути надо
понять как реализуются "права в рамках ОС".

в ман это где-нибудь есть? Почитать бы...

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Здравствуйте, Alexander.

Вы писали 22 Октябрь 2003 г., 23:14:13:

Да

Быстрый ответ: как правило используются Efective {U,G}ID
(привык к макрорасширениям bash :)

Отлично (и правильно - зачем в рассылке просто цитировать
документацию). Наш метод.
Теперь о документации:
Я бы посоветовал интересную книжку:
Unix. Gestionarea proceselor. Iosif Ignat, Adrian Kacso.
Cluj-Napoca 1999
но боюсь не все знакомы с румынским языком.

Книжка попроще и поновее (только по Linux'у)
Advanced Linux Programming. Mark Mitchel, Jeffrey Oldham, Alex Samuel.(2001)
Посмотрел на свою подборку электроной документации и нашёл несколько интересных
книг:
"The design of the Unix Operating System" by Maurice J. Bach (1986)
"Ядро ОС Linux. Руководство системного програмиста"
Я уверен подобной литературы достаточно, вопрос разве что в языковой
доступности.

Приветствую.

On Wed, 22 Oct 2003, Vasile wrote:

Если это не более 500К пршлите мне на мыло. Лучше просто в текстовом
формате. На Ваше усмотрение что но лучше про unix вообще но можно и
конкретно про Linux. Английский без проблем (но на русском
всеже лучше). Румынского я не знаю.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

В сообщении от 22 Октябрь 2003 02:35 Alexander S. Yurkov написал:

Попробуйте такую команду:

chmod +s /usr/sbin/pppd

On Tue, 21 Oct 2003, Антон Иванов wrote:

А что это означает? Я никогда и ни за какие коврижки не стану исполнять
команду под рутовым логином, если не понимаю, что она делает...:-)

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

On Wednesday, Oct 22, 2003, at 01:52 Europe/Moscow, Alexander S. Yurkov
wrote:

Твою мать... Извините, но тут уже и я вмешаюсь:
RTFM (Read The Fucking Manual)! man chmod!
Да, это не самый приятный ответ, и невежливо к новичку, но человеку уже
и команду сказали, и до этого дискуссия была, но настолько лениться -
это админ или как?

/Alexandre.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

В сообщении от 21 Октябрь 2003 22:10 Alexandre написал:

Блин, вот читаю тут в последнее время кучу флейма, и думаю: рассылка для того,

чтобы проблемы решать, или наставлять на путь истинный? Не нравится вопрос -

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

Вот вам неприятно читать такие вопросы, а ведь многим отвечают "RTFM", и они

начинают писать на linuxbegin статьи на тему типа "почему линукс не есть
рулез", вот, мол, под линуксом сидят одни маньяки, которые даже с другими по-

нормальному общаться не могут. А читать _это_ уже гораздо неприятнее.

Действительно: не нравится вопрос - не отвечайте :)

Подписчиков у нас много и, думаю всегда найдется тот, кто сможет
подробно ответить...

Не воспринимайте любой вопрос в этой рассылке как личный и жизнь будет
веселей :)

Друзья, меньше агрессии и больше позитива!

21 Октябрь 2003 20:10, Alexandre написал:

Александр! Все тоже самое можно было сказать без мата и мягче. Или в
личку :)

Не воспринимайте любой вопрос в этой рассылке как личный и жизнь будет
веселей :)

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

Автору письма с вопросом: полезнее научить людей ловить рыбу, чем
поймать им её один раз, чтобы они не умерли с голоду... Dixi.

Удачи,
/Александр.

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

On Tue, 21 Oct 2003, Alexandre wrote:

Знаете, а мне совсем не интересно, какая там команда. И man chmod я
прочитал раз так на двадцать. При том, что английския я знаю неплохо.
Я же ясно сказал "ЧТО ЭТО ОЗНАЧАЕТ", этого в man нет! Меня не интересует
синтаксис, это я и сам в man прочитаю, меня интересует семантика! Ну а
коль скоро у Вас тут как среди виндовозов все построено на рецептурном
уровне (нажмите такую-то кнопку, дайте такую-то команду - нет разницы!)
без понимания сути и смысла (за что я и ненавижу винду!), то мне тут
делать, как оказывается, нечего... А жаль :-(

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

В сообщении от 22 Октябрь 2003 03:52 Alexander S. Yurkov написал:

В двух словах: команда выставляет тот самый бит suid, о котором вам писал
george <geor***@g*****.ua>; программа с установленным битом suid
запускается от имени владельца, в вашем случае - от root. Подробности:

http://linuxshop.ru/linuxbegin/article348.html
http://www.linuxfocus.org/Russian/January1999/article77.html

P.S. для просмотра этого и других атрибутов файла используйте такую команду:

ls -g файл, например

[anton@localhost linux-2.6.0-test7]$ ls -g /usr/sbin/pppd
-rwsr-sr-t 1 root 239192 Авг 9 2002 /usr/sbin/pppd*
здесь буква s показывает, что бит suid установлен.

On Tue, 21 Oct 2003, Антон Иванов wrote:

владельца файла, надо полагать..

Вроде понятно. Спасибо.

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

http доступа нет а с почтовыми службами скачивания я пока не разобрался.

Интересно, а как это (атрибуты файла) в двоичном виде будет. Причем все
какие есть атрибуты. Ну и самое главное смысл этих атрибутов. В моем man
об этом, почему-то только применительно к ключам rwx и все...:-(
Я и думал, что есть только по три бита для владельца, группы и всех
остальных. Впрочем, в символьном виде упоминаются еще атрибуты,
но без ясного об'яснения смысла. Вообще, сколько ни читаю книги (только
какие попадаются), документацию (какая есть), кругом сплошь все в
"репцептурном виде" а я хочу понимать "что, как и почему" :-)
Например меня уже лет так двадцать :-) интересует такой вопрос:
почему в юниксе пророждение процессов производится путем копирования
процесса в новый (fork). Ясно, что так можно, но чем это лучше, чем просто
создать новую системную таблицу процесса...

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Hi Alexander S. Yurkov!!!

Wednesday, October 22, 2003, 3:19:57 AM, you wrote:

прежде чем разглагольствовать о семантике, неплохо бы все таки читать
ман:

man chmod

...........................
A numeric mode is from one to four octal digits (0-7),
derived by adding up the bits with values 4, 2, and 1.
Any omitted digits are assumed to be leading zeros. The
first digit selects the set user ID (4) and set group ID
(2) and save text image (1) attributes. The second digit
selects permissions for the user who owns the file: read
(4), write (2), and execute (1); the third selects permis-
sions for other users in the file's group, with the same
values; and the fourth for other users not in the file's
group, with the same values.

From Russia with love
mailto:serge***@o*****.ru

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Здравствуйте, Alexander.

Вы писали 22 Октябрь 2003 г., 2:19:57:

Можно и не копировать (почти!) используя vfork(), или в более общем
случае clone().

На самом деле это очень удобно в програмировании (дело привычки).
Дело в том что код child процесса не всегда содержится в
отдельном программном модуле (1); стандартной единицей исполнения
кода в Unix является процесс (по историческим причинам), потоки
же (threads) появились гораздо позднее (при этом для их
реализации, в случае POSIX threads, используются опять же
процессы) (2); практический пример - как организовать конвейер
(pipeline): родительский процесс вызывает pipe() и открывает
вход/выход конвейера, после этого fork(), дочерний процесс
получает свою копию дескрипторов возвращённых pipe(), теперь он
уже может общаться с родителем или реализовав подстановку
файловых дескрипторов (с помощью dup(), dup2(), close()) вызвать
другой исполняемый модуль (execve()) который понятия иметь не
будет что по stdin/stdout он общается не с пользователем, а с
другим процессом (3); и в целом так получается гибче, а значит
мощнее (с точки зрения програмиста) (4).
Может это в каком то случае и менее оптимально, но наверное
стоит ясно представлять для чего может понадобится "новая
(пустая!!!) системная таблица процесса".

On Tue, 21 Oct 2003 21:52:42 +0000 (GMT), Alexander S. Yurkov
<fit***@o*****.com> wrote:

$ man chmod (можно не из под рута ;))

Если влом читать: добавить suid-бит к /usr/sbin/pppd
Прогу запускает обычныю юзер но у нее права рута.

Это если suid-бит установлен у проги пользователь-владелец которой root.
Т.е. если пользователь-владелец "xman" и мы устанавливаем suid, а затем пытаемся
выполнить данную команду от имени "xwoman", то запущенная программа
все равно будет выполняться с правами "xman".

C уважением, Kolotov Alexandr aka mr. Эбола
отвечать: myscri***@e*****.ru
ICQ: 100349254

| Registered Linux user # 236664 |
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Hi Kolotov Alexandr!!!

Friday, October 24, 2003, 2:57:07 PM, you wrote:

А вот интересно, для процессов запущенных рутом все суид/сгид биты
игнорируются на ряду с остальными правами, так получается?

From Russia with love
mailto:serge***@o*****.ru

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

и очень даже хорошо получается, а то имела бы место быть ситуация подобная с
пользователем SYSTEM в Windows, т.е. когда администратор не может снять задачу
или зайти в какую-то папку. ИМХО, - бред!

C уважением, Kolotov Alexandr aka mr. Эбола
отвечать: myscri***@e*****.ru
ICQ: 100349254

| Registered Linux user # 236664 |
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

On Fri Oct 24, 2003 at 10:21:46PM +0400, Kolotov Alexandr wrote:

с

Почему же бред :) Очень даже весело М$ придумала.
Я в универе в свою личную папку скинул 5-ть фильмов,
убрал из доступа админов и SYSTEM (случайно). Теперь никто не может
понять куда 3 гиктара пропало.

:ChiP:.

:wq

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

Доброе время суток!
В сообщении от 21 Октябрь 2003 15:50 d2r написал:

А вы на glibc смотрели? RedHat кажется их тоже под конкретный проц
собирало.

--
With best wishes,
Mike Zelenkin mailto:mzelenk***@a*****.ru

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru

В сообщении от Вторник 21 Октябрь 2003 17:50 d2r написал(a):

У меня Р166 32М оперативы RedHat 9.0 всё отлично работает...(Apache,MySQL)

Ставил всё на нём же, сначала на своём PIII 1GHz поставил на тот хард но проблема
та же была....
Решил ставить на него хард и так пробовать.... 2 часа и всё встало....

Привет/Здравствуй/Здравствуйте NixoiD,
(нужное подчеркнуть, ненужное зачеркнуть)

В пятница, 17 октября 2003 г. в 14:22, ты/Вы писАл/писАла/писАли:

А может ты нажал Ctrl+S или ScrollLock? Тогда попробуй
еще раз нажать эти же кнопки или Ctrl+Q.

On Sat Oct 25, 2003 at 12:50:36PM +0600, Ivan Antipin wrote:

попробуй нарабрать "в слепую"
reset

:ChiP:.

:wq

-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.linux.discuss&email=
http://subscribe.ru/ mailto:ask@subscribe.ru