Нет никакого механизма для использования аргументов в тексте замены, как в csh. Если аргументы необходимы, функция оболочки должна использоваться. См. Справочник Bash:: 6.6 Псевдонимы
Может ли такой вывод быть использован, зависит от терминальной программы, и что тот терминал делает в зависимости от управляющих кодов, которые отправляются. Я не знаю, что терминальные программы имеют такие годные для использования функции, и единственная проблема теперь состояла бы в том, если существует неизвестное переполнение буфера или что-то как этот, который мог бы быть использован.
С некоторыми более старыми hardware
терминалы это могло быть проблемой, поскольку Вы запрограммировали, например, функциональные клавиши с подобными escape-последовательностями путем хранения последовательности команды для того ключа в аппаратных средствах. Вам все еще было бы нужно физическое нажатие клавиши для активации этого.
Но всегда существуют (как Hauke, таким образом, законно отметил 'braindead'), люди, готовые добавлять такую опцию, если это решает проблему для них, не понимая лазейку они создают. По моему опыту, с программным обеспечением с открытым исходным кодом то, что, из-за многих глаз, смотрящих на код, это, менее вероятно, произойдет как с закрытым исходным кодом. (Я помню, что в почтовой программе на Irix Grahpics Кремния, в середине девяностых, Вы могли включать команды, которые будут выполняться на машине получателей, реальных путях к исполняемым файлам....),
Большинство эмуляторов терминала передаст некоторый ответ обратно, если они получат определенные escape-последовательности (взгляните на xterm документацию управляющих последовательностей). Например, можно отправить \e[0c
к подобному VT100 эмулятору и это передаст обратно атрибуты устройств, что-то как \e[?1;2c
(Это, вероятно, что наблюдал Keith.), Но эти ответы не являются произвольными строками. Однако, называя исполняемый файл 2c
где-нибудь в Вашей системе, которая делает что-то фатальное, плохая идея.
Обновление: риски на самом деле больше, чем я думал, из-за возможности установить заголовок xterm окна и передать заголовок обратно с помощью соответствующих escape-последовательностей (http://www.securityfocus.com/bid/6940/). В отличие от примера выше, заголовок может быть почти произвольной строкой.
Я определенно испытал xterm
вставка произвольных символов в себя, как будто я ввел их. И при случае это, по-видимому, включало символ новой строки, так, чтобы я добрался ngwerm:0riu: command not found
как ответ. Я не вижу оснований, почему кто-то не мог обработать файл, который отправит определенные, вредные команды. Таким образом да, по крайней мере некоторые терминалы восприимчивы к нападениям с произвольным влиянием.
Это изменяет терминальный заголовок в Терминале 3.6.1 GNOME, если не переопределено чем-то как PS1:
printf "\033]2;Script Kiddie was here\007"
Теперь откройте новое Окно терминала GNOME для тестирования cat
версия:
printf "\033]2;Script Kiddie was here\007" > test.bin
cat test.bin
Да, это также устанавливает терминальный заголовок.
Раньше была проблема безопасности с управляющим кодом, приводящим к заголовку, распечатанному к командной строке, таким образом, Вы могли эффективно создать файл, который когда cat
редактор распечатал бы (я не уверен, могли ли Вы поместить новую строку там), произвольные команды. Ай!
Ну, эмулятор терминала в основном просто распечатывает символы, отправленные в него.
Что-либо помимо простой печати символа на текущей позиции, как установка нового положения, изменение цвета, изменение заголовка, и т.д., сделано escape-последовательностями.
Набор поддерживаемых escape-последовательностей обычно состоит из четко определенных стандартов как ANSI, который не определяет способ запустить другие процессы. Хотя было бы возможно реализовать такую последовательность, я не знаю ни о каком эмуляторе терминала, намеренно позволяющем такие вещи.
В теории ошибка как переполнение буфера могла бы использоваться для инициирования произвольной функциональности. Но это было бы возможно в в значительной степени любом другом двоичном файле, также.
В целом обычно нет никакого риска для catting произвольного файла. Мой обычный метод для анализа файла должен сделать следующее:
$ file <mystery file>
$ strings <mystery file> | less
Вышеупомянутое позволяет мне определять тип файла через file
команда и strings
команда позволяет мне выводить любые идентифицируемые строки от потенциальных двоичных файлов что я "m не уверенный в их происхождении.
$ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
строки производятся
$ strings /bin/ls|less
...
across
vertical
single-column
force
never
auto
if-tty
slash
%b %e %Y
%b %e %H:%M
long-iso
main
posix-
sort_files
?pcdb-lswd
dev_ino_pop
Try `%s --help' for more information.
Usage: %s [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuvSUX nor --sort.
Mandatory arguments to long options are mandatory for short options too.
-a, --all do not ignore entries starting with .
-A, --almost-all do not list implied . and ..
...
При использовании cat
не мог бы привести к выполнению кода, управляющие коды будут обработаны так, Вы могли легко быть введены в заблуждение в размышление, что сценарий безопасен, когда на самом деле это злонамеренно.
Вот пример, управляют, чтобы можно было работать, который создаст "злонамеренный" сценарий оболочки:
echo -e '#!/bin/sh\necho "...doing something bad here..."\nexit\n\033[A\033[Aecho "Hello dear reader, I am just a harmless script, safe to run me!"' > demo.sh
chmod a+x demo.sh
При осмотре файла это кажется достаточно безопасным:
$ cat demo.sh
#!/bin/sh
echo "Hello dear reader, I am just a harmless script, safe to run me!"
Но если Вы на самом деле выполняете его...
$ ./demo.sh
...doing something bad here...
Работы сценария включением необработанных управляющих кодов для перемещения курсора несколько строк, таким образом, остальная часть сценария записана поверх вредоносного кода, скрыв его.
Почти любая другая программа покажет сценарий для того, каково это. Только программы, которые не обрабатывают содержание файла (как cat
, more
и less -r
) произведет вводящий в заблуждение вывод.
Отметьте это tail
и head
также произведите тот же вводящий в заблуждение вывод. Используя "меньшее количество +F" поэтому более безопасно, чем "хвост-f".
echo $(cat demo.sh)
, cat demo.sh | grep . --color=yes
(Примечание: --color=yes
то, что показывает "злонамеренный" код здесь), или сборка - в cat -v demo.sh
.
– Charlie
25.04.2015, 01:02
cat
в отображении содержания файла.
– Incnis Mrsi
18.09.2015, 00:37
cat
произвольный файл, как вопрос, который задают!
– Malvineous
19.09.2015, 02:22
write
команда - таким образом выполняющиеся команды/сценарии как пользователь, владеющий терминалом. Это - предположительно, причина, почему многие рекомендуют выключить сообщенияmesg -n
для пользователей большую часть времени, и дляroot
всегда. AFAIK, это было на самом деле сделано - хотя я не знаю, использовался ли он когда-нибудь. Так случайный текст от acat
ворошите исполняемый файл, мог, возможно, быть выполнен. – Baard Kopperud 26.04.2013, 12:29