BashTex | Linux

Создание honeypot-директории с мониторингом через inotify Honeypot-директория - это ловушка для злоумышленников: специальная папка, куда никто не должен лазить, но если вдруг кто-то туда сунулся - ты узнаешь первым. С помощью inotifywait и bash можно создать простую систему наблюдения за такими "приманками". 1️⃣ Создаем honeypot-директорию

mkdir -p /opt/.honeypot
chmod 700 /opt/.honeypot

Можно добавить туда пару "интересных" файлов: passwords.txt, backup.tar.gz. 2️⃣ Скрипт для мониторинга

#!/bin/bash
WATCH_DIR="/opt/.honeypot"
LOG="/var/log/honeypot_access.log"

inotifywait -m -e access,modify,create,delete "$WATCH_DIR" --format '%T %w %f %e' --timefmt '%F %T' |
while read event; do
  echo "[ALERT] $event" >> "$LOG"
  echo "[ALERT] Honeypot accessed: $event"
  # Можно добавить: уведомление в TG, systemd-notify и т.д.
done

Этот скрипт не завершится, пока не остановлен вручную - запускай как systemd-сервис или в screen/tmux. ➕ Почему это полезно? 📍 Выявление локальных злоумышленников или скомпрометированных процессов; 📍 Алерт при попытке доступа даже от root, если забыли, что это ловушка; 📍 Возможность записывать все действия, включая дату, время и тип события; BashTex 📱 #bash #security

Управление псевдотерминалами Псевдотерминалы (PTY) - это то, что позволяет запускать оболочки, эмулировать сессии и автоматизировать взаимодействие с CLI-программами, которые ждут ввода. В linux есть несколько инструментов, которые можно использовать для работы с ними. ▪️ script - захват сессии в PTY

script -q -c "top -n 1" session.log

Команда выполнится в псевдотерминале, а весь вывод будет сохранен, как будто это была обычная интерактивная сессия. Полезно: для логгирования; обхода нестандартного поведения программ без TTY. ▪️ socat - соединение PTY с чем угодно. Создание виртуальной пары PTY-устройств:

socat -d -d pty,raw,echo=0 pty,raw,echo=0

Это выведет два устройства /dev/pts/X и /dev/pts/Y, которые можно использовать, например, чтобы связать скрипт и программу, как будто они "болтают" друг с другом. Применения: имитация COM-портов; отладка CLI-программ; организация проброса ввода/вывода. ▪️ expect - автоматизация интерактивных CLI

#!/usr/bin/expect -f

spawn ssh user@host
expect "password:"
send "supersecret\r"
interact

expect ждет определенный вывод и отправляет нужный ввод. Это незаменимо, когда скрипт должен работать с программой, которая не поддерживает аргументы, только ручной ввод. ❓ Когда это нужно? 📍 автоматизация SCP, FTP, SSH при отсутствии ключей; 📍 создание тестов CLI-интерфейсов; 📍 запуск GUI-оберток над TUI-программами; 📍 обход "упрямых" команд, требующих TTY (sudo, passwd, mysql, и др.); BashTex 📱 #bash #utils

Автоматическое обновление /etc/hosts из внешнего списка блокировки рекламы Хотите заблокировать рекламу, трекеры и телеметрию на уровне всей системы, без прокси и сторонних приложений? Достаточно обновлять /etc/hosts из надежных источников, таких как someonewhocares.org или StevenBlack. И все это можно автоматизировать с bash. 🛠 Скрипт обновления /etc/hosts

#!/bin/bash
set -euo pipefail

# Источник обновленного hosts-файла
URL="https://someonewhocares.org/hosts/hosts"

# Временный файл
TMP="/tmp/hosts_blocklist"

# Бэкап текущего hosts
cp /etc/hosts "/etc/hosts.bak.$(date +%s)"

# Скачиваем и фильтруем список
curl -s "$URL" | grep -vE '^#|^$' > "$TMP"

# Объединяем с локальной частью
{
  grep -E "^127\.0\.0\.1|^::1" /etc/hosts.bak.* | head -n 2
  echo -e "\n# 🔒 AdBlock entries:"
  cat "$TMP"
} > /etc/hosts

echo "/etc/hosts обновлен. Всего $(wc -l < "$TMP") заблокированных адресов."

▪️ Автоматизация через cron. Добавим задачу раз в неделю:

(crontab -l; echo "0 4 * * 0 /usr/local/bin/update-hosts.sh") | crontab -

➕ Преимущества: Блокировка на уровне ОС - работает в браузерах, терминале, приложениях; Никаких прокси, VPN, расширений; Работает даже в headless-системах. 🌟 Редактирование /etc/hosts требует root-прав, а некоторые адреса могут ломать нужные функции (whitelist нужно продумывать). BashTex 📱 #bash #utils

Скрытые сенсоры системы в скриптах Когда bash-скрипт работает в продакшене, важно понимать окружение: доступные ресурсы, нагрузку, ограничения. Знакомимся: getconf, ulimit, vmstat, iostat - системные команды, которые можно встраивать прямо в bash для более "умных" решений. ▪️ getconf: узнать параметры системы

echo "Page size: $(getconf PAGESIZE)"
echo "Максимум аргументов в командной строке: $(getconf ARG_MAX)"

Можно использовать перед запуском ресурсоемких команд, чтобы адаптировать размер батчей, буферов и т.д. ▪️ ulimit: узнать и задать ограничения

echo "Открытых файлов можно: $(ulimit -n)"
ulimit -c 0  # Запретить core dumps

Полезно перед форком процессов: не дайте скрипту уронить систему из-за 10000 открытых файлов. ▪️ vmstat: мониторинг памяти и нагрузки

vmstat 1 2 | tail -1 | awk '{print "Свободная память: " $4 " KB, ожидание I/O: " $16}'

Используй для самодиагностики скриптов: если скрипт замечает, что система в swap - можно приостановить запуск тяжелых задач. ▪️ iostat: здоровье диска

iostat -dx 1 2 | grep sda | tail -1 | awk '{print "IO util: " $NF "%"}'

Если util% > 90 - диск перегружен. Скрипт может решить подождать или отложить копирование. ▪️ Пример: скрипт отложенного запуска при перегрузке

wait_for_idle() {
  while :; do
    util=$(iostat -dx 1 2 | awk '/sda/ {u=$NF} END{print int(u)}')
    [[ $util -lt 50 ]] && break
    echo "Диск занят ($util%), ждём..."
    sleep 5
  done
}

Скрипты могут быть "умными", если читают данные от системы: не запускай, если ресурсов нет, не ломай лимиты. BashTex 📱 #bash #utils

2025 год: ИИ, облака и… дыры в Kubernetes? Тренды меняют индустрию: компании переходят в облака, внедряют ИИ, автоматизируют всё. Но чем сложнее инфраструктура, тем проще оставить брешь в безопасности. Особенно в Kubernetes: ◼️ незакрытый дашборд — и вот уже криптомайнеры используют ваш кластер; ◼️ под с root-доступом — и злоумышленник получает контроль над нодой; ◼️ логи с паролями доступны бывшим сотрудникам — и вот уже вы находите их в сливах. Даже если работаете с k8s давно, не факт, что вы знаете все нюансы безопасности в Kubernetes! Что делать? Прокачивать security. 👉 4 августа стартует практический курс «Безопасность в Kubernetes», на котором вы на реальных кейсах научитесь обеспечивать безопасность контейнера, а с ним и проекта, и максимально усложнять жизнь злоумышленникам. 🔥 Можно забрать со скидкой 50% по промокоду LETO2025! Узнать подробности и занять место на курсе — по ссылке.

🎉 С днем системного администратора! 🎉 Сегодня не будет познавательных постов, но будет не менее важное - поздравление! Сегодня - день тех, кто всегда остается за кулисами, но без кого не работает ничего. Это вы начинающие или уже опытные - волшебники командной строки, мастера uptime и защитники серверов от хаоса. Именно Вы держите на плаву сети, базы данных, почту, бэкапы, мониторинг, безопасность и еще тысячу вещей, о которых никто не догадывается... пока все не сломается, ну или им не покажется, что все сломалось.. Буду короток: пусть в логах будет чисто, аптайм радует глаз, а пользователи не беспокоят в пятницу вечером. А еще - стабильных обновлений, бесшумных серверов и свободного времени для себя. За вас, сисадмины! С праздником! 🎆 BashTex 📱

🐧Нашли для вас самый крутой блог Администратора Linux На своëм канале он уже осветил такие темы, как: — Что такое ядро Linux и зачем оно нужно? — Как защитить свой Linux от взлома — Как создать собственный ISO-образ в Linux — Linux и управление пакетами — Процессы в Linux и отладка зависаний 👀Подписывайся, чтобы не потерять

Запрет доступа к конфигурационным файлам через AppArmor Даже если у вас настроены права доступа на конфиги (/etc/shadow, /etc/ssh/sshd_config, /etc/fstab), это не исключает попыток обхода через эксплойты или скомпрометированные процессы. Решение: AppArmor + аудит + реакция. 1️⃣ Базовый профиль AppArmor. Пример для блокировки доступа к sshd_config сторонними процессами:

# /etc/apparmor.d/usr.local.block-ssh-access
#include <tunables/global>

/usr/local/bin/* {
  deny /etc/ssh/sshd_config r,
}

Разрешаем запуск всего в /usr/local/bin, но явно запрещаем доступ к sshd_config. ▪️ Активация профиля

sudo apparmor_parser -r /etc/apparmor.d/usr.local.block-ssh-access

Профиль будет применен сразу. Проверка:

aa-status

2️⃣ Анализ логов AppArmor. Все попытки нарушения будут фиксироваться в dmesg или /var/log/kern.log / /var/log/syslog: Пример:

audit: type=1400 audit(…): apparmor="DENIED" operation="open" profile="/usr/local/bin/myscript" name="/etc/ssh/sshd_config"

3️⃣ Скрипт для анализа и алерта

#!/bin/bash
LOG="/var/log/syslog"
ALERT="/var/log/apparmor_violations.log"

grep "apparmor=\"DENIED\"" "$LOG" | grep "/etc/ssh/sshd_config" >> "$ALERT"

if [[ -s $ALERT ]]; then
    echo "[ALERT] Попытка доступа к sshd_config:"
    cat "$ALERT"
    > "$ALERT"  # Очистка после отчёта
fi

Можно запустить через cron или systemd-timer. ❓ Зачем это нужно: 📍 Ужесточение защиты конфигов от неожиданных процессов; 📍 Мониторинг попыток обхода прав через утилиты; 📍 Интеграция с TG или почтой для оповещений BashTex 📱 #bash #security

Пушистый сделал правильный выбор BashTex 📱 #юмор

Симуляция транзакций в Bash В bash нет настоящих транзакций. Но что, если тебе нужно выполнить серию изменений, и в случае ошибки все откатить обратно? Это возможно - через копии, trap, проверку ошибок и откат действий вручную. ▪️ Пример: изменение конфигов с возможностью отмены

#!/bin/bash
set -euo pipefail

CONFIG="/etc/myapp/config.conf"
BACKUP="/tmp/config.conf.bak.$RANDOM"

# Создаём резервную копию
cp "$CONFIG" "$BACKUP"

# Обработчик при ошибке
rollback() {
  echo "Ошибка! Откатываем изменения..."
  cp "$BACKUP" "$CONFIG"
  echo "Конфиг восстановлен."
}
trap rollback ERR

echo "Обновляем конфиг..."
# Имитация изменения
echo "enable_feature=true" >> "$CONFIG"

# Имитация ошибки
false  # или команда, которая может упасть

echo "Конфиг успешно обновлён"
rm "$BACKUP"

▪️ Объяснение: 📍 trap rollback ERR - ловит любую ошибку 📍 set -euo pipefail - строгий режим, ошибки не скрываются 📍 Копия - это наша "точка восстановления" 📍 После успешного выполнения - копия удаляется ▪️ Применение:

Обновление конфигов Копирование и изменение сервисных файлов Манипуляции с crontab, systemd, hosts, fstab Авторазвертывание с откатом при сбое

Это простая, но классная техника: bash-транзакции как ручной аналог ACID. BashTex 📱 #bash #utils

Bash-сборка .deb пакета из локального проекта с автогенерацией changelog Хочешь упаковать свой скрипт, бинарник или мини-сервис в .deb, не лезя в dh-make и ручное правописание changelog? Делается это всего за пару минут с bash-автоматизацией. ▪️ Структура проекта. Пример для утилиты mytool:

mytool/
├── usr/
│   └── local/
│       └── bin/
│           └── mytool
└── DEBIAN/
    └── control

▪️ DEBIAN/control (пример)

Package: mytool
Version: 1.0.0
Section: utils
Priority: optional
Architecture: all
Maintainer: You <admin@bashtex.ru>
Description: Утилита для всего

▪️ Генерация changelog из git

generate_changelog() {
  git log -n 10 --pretty="  * %s (%h)" > changelog.txt
  echo "mytool (1.0.0) stable; urgency=low" | cat - changelog.txt > DEBIAN/changelog
  rm changelog.txt
}

▪️ Сборка .deb

build_deb() {
  chmod -R 755 mytool/DEBIAN
  dpkg-deb --build mytool
}

▪️ Автоматизация в bash

#!/bin/bash
set -e

PKG_DIR="mytool"
VERSION="1.0.0"
PKG_NAME="mytool_${VERSION}.deb"

generate_changelog() {
  git log -n 10 --pretty="  * %s (%h)" > "$PKG_DIR/DEBIAN/changelog"
}

build_deb() {
  chmod -R 755 "$PKG_DIR/DEBIAN"
  dpkg-deb --build "$PKG_DIR" "$PKG_NAME"
  echo "Пакет создан: $PKG_NAME"
}

generate_changelog
build_deb

Теперь можно установить пакет через dpkg -i mytool_1.0.0.deb, а в /usr/local/bin/ появится твой скрипт. BashTex 📱 #bash #utils

Self-test для скриптов: проверка зависимостей, путей и прав доступа перед выполнением Self-test в начале скрипта - это мини-проверка, которая убеждается, что все окружение готово: утилиты установлены, пути доступны, директории пишутся. Без этого легко получить «тихий фэйл». Добавим в скрипт проверку еще до основной логики. 🛠 Пример базового self-test блока

#!/bin/bash

# 💥 Включаем строгий режим
set -euo pipefail

#Список зависимостей
REQUIRED_CMDS=("curl" "jq" "awk")

#Каталоги, которые должны существовать и быть доступны
REQUIRED_DIRS=("/var/log/myapp" "/etc/myapp")

#Проверка утилит
for cmd in "${REQUIRED_CMDS[@]}"; do
  command -v "$cmd" >/dev/null 2>&1 || {
    echo "Требуется утилита '$cmd', но она не найдена"
    exit 1
  }
done

#Проверка директорий
for dir in "${REQUIRED_DIRS[@]}"; do
  [[ -d "$dir" ]] || {
    echo "Каталог $dir не существует"
    exit 1
  }
  [[ -w "$dir" ]] || {
    echo "Нет прав на запись в $dir"
    exit 1
  }
done

#Проверка прав запуска от root (если нужно)
if [[ $EUID -ne 0 ]]; then
  echo "Скрипт должен быть запущен от root"
  exit 1
fi

echo "Self-test пройден успешно. Продолжаем выполнение..."

❓ Что еще можно проверять? 📍 Наличие переменных окружения 📍 Работу с удаленными API (curl --silent --fail) 📍 Целостность файлов настроек 📍 Доступность сервисов (systemctl is-active) BashTex 📱 #bash

🎉 Большой розыгрыш от крупнейшего IT-медиа 1337, легендарного паблика Рифмы и Панчи, канала Техно. Победителей будет много, а для участия нужны лишь пара кликов: 1. Подписаться на Рифмы и Панчи, 1337 и на Техно. 2. Нажать «Участвовать» под этим постом Что по призам:

1 место - Iphone 16 Pro 2 место - PS5 Slim 3 место - Nintendo Switch 2 4-10 места - 10 000 рублей на карту

Победителей определим 21 июля в 18:00 МСК. Всем удачи!

Асинхронное логирование bash-скриптов с метками времени Когда скрипт выполняет много команд, хочется: видеть вывод в реальном времени, сохранить лог в файл, добавить метки времени и не тормозить скрипт тяжелым tee в цикле. Вот асинхронный способ, как это сделать. ▪️ Подход: через mkfifo и фоновый логгер

#!/bin/bash

LOG_FILE="script.log"
PIPE="/tmp/pipe.$$"

# создаем именованный канал
mkfifo "$PIPE"

# логгер: читает из канала, добавляет таймштамп и пишет в файл
tee "$LOG_FILE" < "$PIPE" |
while IFS= read -r line; do
  echo "[$(date '+%Y-%m-%d %H:%M:%S')] $line"
done &

# перенаправим stdout и stderr скрипта в канал
exec > "$PIPE" 2>&1

# ———————————————
echo "Скрипт стартовал"
sleep 1
echo "Работаем..."
ls /nonexistent/path
echo "Завершено"
# ———————————————

wait
rm "$PIPE"

🌟 Что получаем:

📍 Вывод в терминале с метками времени 📍 Лог сохраняется в файл без stdout-мусора 📍 Работает асинхронно: скрипт не ждёт tee/while 📍 Поддерживает stderr

Файл script.log будет без меток времени - идеально для машинной обработки На экране - человекочитаемый лог BashTex 📱 #bash #utils

В этот раз все будет хорошо BashTex 📱 #юмор

Парсим YAML и TOML в bash без внешних зависимостей YAML и TOML - популярные форматы конфигураций. Но в чистом bash их разбирать - задача нетривиальная. Особенно если не хочешь тащить yq, shyaml, python и toml-cli. Разберемся, как выжать максимум из awk, grep, IFS и других стандартных средств. ▪️ YAML (только простые key: value)

parse_yaml() {
  grep '^[^#[:space:]].*:' "$1" | awk -F': ' '
    NF == 2 { gsub(/"/, "", $2); print $1 "=" $2 }
  '
}

Пример:

# config.yaml
port: 8080
host: localhost
debug: true

Вызов:

eval $(parse_yaml config.yaml)

echo "$host:$port"   # → localhost:8080

Не поддерживает вложенные уровни и массивы - только flat YAML. ▪️ TOML (ключ=значение)

parse_toml() {
  grep -v '^\s*#' "$1" | grep '=' | while IFS='=' read -r key val; do
    key=$(echo "$key" | xargs)
    val=$(echo "$val" | sed -E 's/^["'\'']//; s/["'\'']$//' | xargs)
    echo "$key=$val"
  done
}

Пример:

# config.toml
user = "admin"
port = 9000

Вызов:

eval $(parse_toml config.toml)

echo "$user:$port"  # → admin:9000

🟩 Преимущества 📍 Легко встраивается в скрипты 📍 Не требует ничего, кроме POSIX-инструментов 📍 Можно логировать значения или сохранять в массивы 🔲 Ограничения 📍 Нет поддержки массивов, вложенных таблиц, якорей 📍 YAML с отступами, списками и вложениями - не обработается BashTex 📱 #bash

Эмуляция очереди и стека в Bash: играем с массивами как в CS101 В bash можно не только писать условия и циклы, но и реализовать базовые структуры данных. Сегодня - очередь (FIFO) и стек (LIFO) - с помощью обычных массивов. ▪️ Стек (LIFO). Последним пришел - первым ушел.

stack=()

# push
stack+=("первый")
stack+=("второй")

# pop
last_index=$(( ${#stack[@]} - 1 ))
echo "POP: ${stack[$last_index]}"
unset 'stack[$last_index]'

После этого в стеке остается только "первый". ▪️ Очередь (FIFO). Первым пришел - первым ушел.

queue=()

# enqueue
queue+=("alpha")
queue+=("beta")

# dequeue
echo "DEQUEUE: ${queue[0]}"
queue=("${queue[@]:1}")

Мы просто “срезаем” массив начиная с элемента 1. ▪️ Пример: обработка задач в очереди

queue=("job1" "job2" "job3")

while [[ ${#queue[@]} -gt 0 ]]; do
  task="${queue[0]}"
  echo "Processing $task"
  queue=("${queue[@]:1}")
done

▪️ Условно реальный стек

push()  { stack+=("$1"); }
pop()   { echo "${stack[-1]}"; unset 'stack[-1]'; }
peek()  { echo "${stack[-1]}"; }

С bash версии 4+ можно использовать [-1] для получения последнего элемента. 🌟 Минусы: 📍 Нет указателей, только пересоздание массива; 📍 Производительность не сравнима с языками типа Python, но работает. BashTex 📱 #bash #utils

Запуск команд от имени другого пользователя через su/sudo без пароля Иногда нужно запустить команду от другого пользователя - без постоянного ввода пароля. Например: от имени сервисного пользователя без логина; в скриптах автоматизации; при делегировании задач. Используем sudo с NOPASSWD и su с передачей команды. 1️⃣ Способ: sudo без пароля. Для этого отредактируем sudoers через:

sudo visudo

Добавим строку:

myuser ALL=(targetuser) NOPASSWD: /usr/bin/systemctl restart my-service

Теперь можно запускать:

sudo -u targetuser /usr/bin/systemctl restart my-service

Или сразу выполнять произвольную команду:

sudo -u deployuser /home/deployuser/scripts/deploy.sh

2️⃣ Способ: su без пароля (через sudo-права). Если sudo уже доступен, можно делать:

sudo su - otheruser -c 'echo $HOME'

Это полезно, если нужна изоляция окружения (su - сбрасывает переменные). ▪️ Пример в скрипте:

#!/bin/bash

USER=deploy
CMD="/opt/app/update.sh"

sudo -u "$USER" bash -c "$CMD"

Обязательно ограничь sudo на конкретную команду в sudoers, чтобы избежать эскалации. 🌟 Безопасность: 📍 Не давай NOPASSWD на ALL! 📍 Всегда указывай полный путь к команде 📍 Используй visudo, чтобы не сломать конфигурацию BashTex 📱 #bash #utils

Выявление SUID-бинарей и контроль их изменений 🌟 SUID-файлы в Linux - это потенциальная зона риска. Если злоумышленник сможет изменить или подменить такой бинарник, он может получить права root. Поэтому важно не только найти такие файлы, но и отслеживать их изменения. SUID (Set User ID) - бит прав, при котором программа выполняется с правами владельца файла, а не вызывающего пользователя. Типичный пример:

ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 54256 /usr/bin/passwd

SUID-бит (s вместо x) на позиции владельца. 1️⃣Поиск всех SUID-файлов в системе

find / -perm -4000 -type f 2>/dev/null

Добавим форматированный вывод с размером и датой:

find / -perm -4000 -type f -exec ls -lh {} \; 2>/dev/null

2️⃣ Контроль изменений через контрольные суммы. Создадим базовый снимок:

find / -perm -4000 -type f -exec sha256sum {} \; 2>/dev/null > /var/log/suid_baseline.sha

А теперь проверим изменения:

sha256sum -c /var/log/suid_baseline.sha 2>/dev/null | grep -v ': OK'

Все, что отличается от baseline, будет отображено. ▪️ Добавить cron-задачу:

@daily root /usr/local/bin/suid_check.sh >> /var/log/suid_monitor.log

И сам suid_check.sh:

#!/bin/bash

BASELINE="/var/log/suid_baseline.sha"
TMP="/tmp/suid_check.$$"

find / -perm -4000 -type f -exec sha256sum {} \; 2>/dev/null > "$TMP"

diff -u "$BASELINE" "$TMP" && cp "$TMP" "$BASELINE"
rm "$TMP"

BashTex 📱 #bash #security

Сканирование домашнего каталога на наличие SSH-ключей и приватных файлов SSH-ключи и приватные файлы часто забывают почистить после миграций, тестов и копирований. Но забытый id_rsa в чужом $HOME - это потенциальная дыра в безопасности. Сегодня про то, как быстро просканировать все домашние каталоги на сервере на наличие: приватных ключей (id_rsa, *.pem, *.key) конфигураций с доступами (.ssh/config, known_hosts) подозрительных backup-файлов (*.bak, *.old, *~) 🛠 Скрипт: поиск чувствительных файлов

#!/bin/bash

echo "[*] Поиск приватных SSH-ключей и чувствительных файлов в /home/*"

find /home /root \
  -type f \
  \( -name "id_rsa" -o -name "*.pem" -o -name "*.key" -o -name "*.bak" -o -name "*.old" -o -name "*~" \) \
  -exec ls -lh {} \; 2>/dev/null

⭐️ Расширенная версия: с владельцем и правами

find /home /root \
  -type f \
  \( -name "id_rsa" -o -name "*.key" -o -name "*.pem" -o -name "*.gpg" \) \
  -printf "%M %u %p\n" 2>/dev/null | sort

▪️ Это поможет заметить, если: 📍 приватный ключ лежит с правами 644 - плохо 📍 файл принадлежит не тому пользователю 📍 ключи забыли в общем ~/Downloads/ или ~/Desktop/ BashTex 📱 #bash #security