LINUX.ORG.RU
← Документация
Soo stable and soo slow →
 ← 1 2

В буфере эмулятора терминала.

GotF ★★★★★
()

man tee

Также смотри screen, в любом случае пригодится. screen умеет вести лог сессии

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

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

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

можешь попробовать восстановить файл, но это вряд-ли... (даже если восстановит, там скорее будет 0 байт)

drBatty ★★
()

Сохраняй вывод в файл, так и делаю.

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

Кстати, а его что, выпилили в свежих версиях util-linux? Ибо в том же Squeeze:

rain@acnote:~$ dpkg -L util-linux | grep script
rain@acnote:~$

хотя в RHEL5 есть:

# rpm -qf `which script `
util-linux-2.13-0.59.el5

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

О. Спасибо. А то packages.debian.org по запросу script послал меня куда подальше, а в системе бинарника не было :)

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

Мне-то оно зачем? У меня все хорошо. Я просто высказал предположение, зачем человеку так понадобился этот вывод.

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

В Ubuntu, похоже, исправлено.

В quantal? У меня 12.04, баг проявляется:

ls -l /proc/2366/fd                     
итого 0
lr-x------ 1 max max 64 Июн 24 19:42 0 -> /dev/null
l-wx------ 1 max max 64 Июн 24 19:42 1 -> /dev/null
lr-x------ 1 max max 64 Июн 24 19:42 10 -> socket:[15205]
lrwx------ 1 max max 64 Июн 24 19:42 11 -> socket:[13132]
lrwx------ 1 max max 64 Июн 24 19:42 12 -> anon_inode:inotify
lrwx------ 1 max max 64 Июн 24 19:42 13 -> /dev/ptmx
lrwx------ 1 max max 64 Июн 24 19:42 14 -> /dev/pts/0
lrwx------ 1 max max 64 Июн 24 19:42 15 -> socket:[16524]
lrwx------ 1 max max 64 Июн 24 19:42 16 -> anon_inode:[eventfd]
lrwx------ 1 max max 64 Июн 24 19:42 17 -> /dev/ptmx
lrwx------ 1 max max 64 Июн 24 19:42 18 -> /tmp/vteLNKQGW (deleted)
lr-x------ 1 max max 64 Июн 24 19:42 19 -> /tmp/vteFLKQGW (deleted)
l-wx------ 1 max max 64 Июн 24 19:42 2 -> /home/max/.xsession-errors
lrwx------ 1 max max 64 Июн 24 19:42 20 -> /tmp/vte3E7KGW (deleted)
lr-x------ 1 max max 64 Июн 24 19:42 21 -> /tmp/vte4S8KGW (deleted)
l-wx------ 1 max max 64 Июн 24 19:42 22 -> /dev/pts/2
lrwx------ 1 max max 64 Июн 24 19:42 23 -> /dev/ptmx
lrwx------ 1 max max 64 Июн 24 19:42 24 -> /tmp/vteLNLLGW (deleted)
lrwx------ 1 max max 64 Июн 24 19:42 25 -> /tmp/vte63MLGW (deleted)
lrwx------ 1 max max 64 Июн 24 19:42 26 -> /tmp/vteOUINGW (deleted)
lrwx------ 1 max max 64 Июн 24 19:42 27 -> /tmp/vteININGW (deleted)
lrwx------ 1 max max 64 Июн 24 19:42 28 -> /dev/pts/3
lrwx------ 1 max max 64 Июн 24 19:42 29 -> /dev/ptmx
lrwx------ 1 max max 64 Июн 24 19:42 3 -> anon_inode:[eventfd]
lrwx------ 1 max max 64 Июн 24 19:42 30 -> /tmp/vteVH6JGW (deleted)
lrwx------ 1 max max 64 Июн 24 19:42 31 -> /tmp/vteZC6JGW (deleted)
lrwx------ 1 max max 64 Июн 24 19:42 32 -> /tmp/vteCH0NGW (deleted)
lrwx------ 1 max max 64 Июн 24 19:42 33 -> /tmp/vteTHR8FW (deleted)
lrwx------ 1 max max 64 Июн 24 19:42 34 -> /tmp/vteNJR8FW (deleted)
lrwx------ 1 max max 64 Июн 24 19:42 35 -> /tmp/vteXDR8FW (deleted)
lrwx------ 1 max max 64 Июн 24 19:42 36 -> /dev/pts/4
lr-x------ 1 max max 64 Июн 24 19:42 38 -> /tmp/vteVI1BGW (deleted)
lr-x------ 1 max max 64 Июн 24 19:42 39 -> /tmp/vteFP0BGW (deleted)
lrwx------ 1 max max 64 Июн 24 19:42 4 -> anon_inode:[eventfd]
lrwx------ 1 max max 64 Июн 24 19:42 5 -> socket:[15204]
lrwx------ 1 max max 64 Июн 24 19:42 6 -> socket:[16512]
lrwx------ 1 max max 64 Июн 24 19:42 7 -> anon_inode:[eventfd]
lr-x------ 1 max max 64 Июн 24 19:42 8 -> anon_inode:[eventfd]
lr-x------ 1 max max 64 Июн 24 19:42 9 -> socket:[16513]
gentoo_root ★★★★★
()
Ответ на: комментарий от KivApple

Почему это собственно баг, а не фича?

Потому что любая программа, работающая от этого пользователя, может стырить весь выхлоп консоли через /proc.

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

Это не совсем уязвимость. Уязвимость это если можно введя некорректные данные, можно выполнить запрещённые действия.

А тут юзер сам запустил приложение, оно абсолютно корректно прочитало файл, к которому был доступ...

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

Уязвимость это если можно введя некорректные данные, можно выполнить запрещённые действия.

Это частный случай.

А тут юзер сам запустил приложение, оно абсолютно корректно прочитало файл, к которому был доступ...

Проблема в том, что этого файла быть не должно. Ну зачем нужно сбрасывать scrollback buffer в файл, сразу же этот файл удаляя? %_%

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

А тут юзер сам запустил приложение, оно абсолютно корректно прочитало файл, к которому был доступ...

А если это не юзер запустил приложение, а, например, был взломан браузер? У delete83 была проблема с chromium'ом: при входе на определённый сайт в конец html'ки добавлялось перенаправление на сайт фишинга. После чистки профиля такое поведение пропало. При этом в другом браузере оно не наблюдалось. Из этого делаем вывод, что нас уже взламывают через дырявые браузеры, в то время как мы совершенно не заботимся о безопасности (да и поделать тут особо нечего). Поэтому вполне возможно, что юзера взломают через браузер, запустят свой код, и этого хватит, чтобы утащить логи консоли и заслать их куда-нибудь.

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

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

Ну так против того, чтобы фиксить уязвимости браузера, я ничего не имею. Там уязвимость вполне попадает под моё определение.

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

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

это не баг, а фича. Как иначе удалить файл если терминал будет закрыт аварийно? А удалять его необходимо, если тебе нужна история, то выше уже про screen говорили. В терминале вполне могут находится конфиденциальные данные.

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

Мне-то оно зачем? У меня все хорошо. Я просто высказал предположение, зачем человеку так понадобился этот вывод.

а если там пароль от чего-нибудь?

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

Потому что любая программа, работающая от этого пользователя, может стырить весь выхлоп консоли через /proc.

можно подумать, весь выхлоп нельзя взять из памяти? К тому-же, инфа и так скорее всего в памяти, ведь запись буферезированая. Можешь сам посмотреть, там инфа неполная.

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

Проблема в том, что этого файла быть не должно. Ну зачем нужно сбрасывать scrollback buffer в файл, сразу же этот файл удаляя? %_%

не, он удаляется ПЕРЕД сбросом. и в этом файле не вся история.

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

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

у меня опасные программы другим юзером запускаются. Потому «вирус в браузере» мне не страшен.

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

1. браузер может сделать скриншот.

2. можно и из памяти выдернуть.

drBatty ★★
()

В man script он хранится.

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

можно подумать, весь выхлоп нельзя взять из памяти?

В нормальной ОС процесс не может прочитать виртуальное адресное пространство другого процесса и вообще что-либо вне своего адресного пространства. А уж тем более не может прочитать физическую память или своп, потому что на их файлы должны стоять соответствующие права доступа.

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

у меня опасные программы другим юзером запускаются.

Очень удобно открывать html'ки с диска и сохранять закачки?

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

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

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

дык его устанавливать надо, потом базу обновлять

Необязательно, если скомпилировать с libastral.so.2

sdio ★★★★★
()

Хренасе, 45+ ответов. Ну, нету по дефолту, так нету. Есть способ сделать, чтобы тот сохранялся куда-нибудь?

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

В нормальной ОС процесс не может прочитать виртуальное адресное пространство другого процесса

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

ЗЫЖ что думаю разрабы, никто не знает? ИМХО плохо хранить в памяти всю историю (она ведь может быть большой).

drBatty ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2
← Документация
General
Soo stable and soo slow →