сценарий удара и локальный огибающий переменный конфликт пространства имен

Вы делаете две вещи неправильно в Вашем примере.

  1. Вы используете блочный шифр. Необходимо будет использовать поточный шифр, такой как rc4 или блочный шифр в режиме CFB (который эффективно превращает его в поточный шифр).
  2. Вы кодируете base64. Как Gilles упомянул, base64 в openssl требует 80-байтового буфера. Устраните кодирование base64, и Вы будете видеть поведение, которое Вы ожидаете.

Пример с aes-128-cfb:

(echo Hello world ; sleep 3) | openssl enc -aes-128-cfb -pass pass:test -bufsize 1 | openssl enc -d -aes-128-cfb -pass pass:test -bufsize 1

Пример с rc4:

(echo Hello world ; sleep 3) | openssl enc -rc4 -pass pass:test -bufsize 1 | openssl enc -d -rc4 -pass pass:test -bufsize 1

Однако я должен указать, что сокращение размера буфера увеличит процессорное время, требуемое выполнить crypto операции:

% time sh -c 'dd if=/dev/urandom bs=8k count=1 | openssl enc -rc4 -pass pass:test | openssl enc -d -rc4 -pass pass:test > /dev/null'
1+0 records in
1+0 records out
8192 bytes transferred in 0.001175 secs (6972350 bytes/sec)
sh -c   0.01s user 0.01s system 167% cpu 0.009 total
% time sh -c 'dd if=/dev/urandom bs=8k count=1 | openssl enc -rc4 -pass pass:test -bufsize 1 | openssl enc -d -rc4 -pass pass:test -bufsize 1 > /dev/null'
1+0 records in
1+0 records out
8192 bytes transferred in 0.001070 secs (7655913 bytes/sec)
sh -c   0.02s user 0.03s system 187% cpu 0.027 total

С буфером 8K это только взяло 0,01 секундам каждого пользователя и системное время, но использование -bufsize 1 занял 0,02 и 0,03 секунды соответственно, общее количество 5x увеличение. Процент использования ЦП сообщил о значении, также увеличенном 20. Если это не проблема для Вас, затем любой ценой используют bufsize 1. Но если это будет, то затем необходимо будет сравнить его для нахождения лучшего размера для приложения.

4
17.04.2019, 01:43
5 ответов
[113884]Переменные оболочки инициализируются из переменных окружения в каждой оболочке, обойти это невозможно.

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

(и имеет [114337]#! /bin/bash -[114338] she-bang), [114339]env[114340] выполнит [114341]/bin/bash[114342] и передаст [114343]VAR_A=xxx[114344] этой команде bash, а [114345]bash[114346] присвоит своей переменной [114347]$VAR_A[114348] значение [114349]xxx[114350].

В оболочке Борна и в C-оболочке, если вы присваиваете новое значение этой переменной оболочки, это не влияет на соответствующую переменную env, передаваемую последующим командам, выполняемым оболочкой, вы должны использовать для этого [114351]export[114352] или [114353]setenv[114354] (обратите внимание, однако, что в оболочке Борна, если вы [114355]unset[114356] присваиваете переменную оболочки, она удаляет и переменную оболочки, и переменную окружения). В:

enter image description here

In:

(с [114357]sh[114358] оболочкой Борна, а не современными POSIX оболочками) или:

другая команда[114360] получает [114361]VAR=xxx[114362] в своем окружении, а не [114363]VAR=yy[114364], вам нужно будет его записать:

или


Для того, чтобы [114365]другая команда [114366] получила [114367]VAR=yyy[114368] в своем окружении.

enter image description here

Однако, [114369]ksh[114370] (и POSIX в результате, а затем [114371]bash[114372] и все другие современные оболочки, похожие на Борна в результате) сломали это.

  1. При запуске этих современных оболочек [114373] привязывают [114374] свою переменную оболочки к соответствующей переменной окружения.
  2. Это означает, что скрипт может засорять окружение, просто установив одну из его переменных, даже если он не экспортирует её. Некоторые оболочки, как известно, удаляют переменные окружения, которые он не может сопоставить с переменными оболочки (поэтому рекомендуется использовать только имена переменных, которые могут быть сопоставлены с оболочкой, для имен переменных окружения)
  3. Это основная причина, по которой все заглавные переменные должны быть зарезервированы для переменных окружения.

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

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

6
27.01.2020, 20:46
[113842]tl;dr:

Не совсем понятно, что вы спрашиваете как "локальная [114295]env переменная[114296]" - это противоречие. Переменные окружения являются глобальными, а не локальными.


У вас есть три типа переменных:

tar xfj filename.tar.bz2 | 7z a -si filename.7z

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

tar xfz filename.tar.gz | 7z a -si filename.7z

глобальные переменные.

локальные переменные.

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

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

cross-ref options

В чистом виде bash, вы не можете этого сделать. Когда сценарий запускается, все переменные окружения экспортируются глобальные переменные. Когда скрипт изменяет [114303]VAR_A[114304], он изменяется в окружении.

Если вы используете Linux, вы можете получить доступ к родительскому окружению через файловую систему [114305]proc[114306]. Родительский процесс обычно имеет исходную переменную окружения, которую вы ищете:

echo -n "Hello World "; uptime

Она извлечет переменную окружения [114307]VAR_A[114308] из окружения родительского процесса ([114309]$PPID[114310]) и распечатает только часть значения. Это зависит от того, сможете ли вы прочитать родительское окружение (тот же самый UID), и что родительская переменная имеет нужную вам переменную.[113859].

3
27.01.2020, 20:46
[113808]Вы можете заставить переменную [114254]VAR_A[114255] читать только добавив строку:

  • в верхней части твоего сценария. Это приведет к тому, что значение [114256]VAR_A[114257] будет [114258]сохранено [114259] в соответствии с вашим локальным окружением.
  • только для чтения: только для чтения [-aAf] [имя[= значение] ...] или только для чтения -p
  • Отметьте переменные оболочки как неизменные. Пометьте каждое ИМЯ как доступное только для чтения; значения этих ИМЯ могут быть не следующими изменено последующим назначением. Если поставляется VALUE, присвоить VALUE перед маркировкой как "только для чтения". Опции: -a ссылаться на индексированные переменные массива -А относится к переменным ассоциативного массива -f относится к функциям оболочки -p отображение списка всех переменных и функций, доступных только для чтения Аргумент `--' отключает дальнейшую обработку опций. Статус выхода: Возвращает успешную обработку, если только не задана недействительная опция или не указано имя.

Paste Special - 2

Следующий пример должен прояснить:

enter image description here

5
27.01.2020, 20:46
[113802] Если вы хотите распечатать [114244] локальную [114245] переменную [114246] VAR_A[114247], вы должны вызвать ее в локальной области видимости, иначе она распечатает значение глобальной переменной [114248]VAR_A[114249]:

Запустите его:

Больше информации о [114250]local[114251] in bash можно прочитать со страницы [114252]man[114253] page:

2
27.01.2020, 20:46

Происходит то, что файл конфигурации VAR_A перезаписывает содержимое VAR_A поступает из .bashrc .

Следовательно, решение напрашивается само собой: перед тем, как исходить из файла конфигурации, сохраните содержимое VAR_A , как показано ниже.

VAR_A_sav=${VAR_A} # assuming that VAR_A_sav does NOT exist in configuration

. ../configuration # that is, you must choose a name not existing in config.

VAR_A=${VAR_A_sav}
1
27.01.2020, 20:46

Теги

Похожие вопросы