Comments 12
Мне кажется, что проще использовать возможности binfmt и запускать jar-ы как обычные исполняемые файлы.
Вспомнилось, как сломав pam использовали «уязвимость» во внутреннем сервисе (доступ был только через vpn), который умел «читать» конфиги на jruby и был запущен с правами рута.
UFO just landed and posted this here
Откуда? В
<some-service>.service пишите: [Unit]
Description=Some java service
[Service]
StartExec=/usr/bin/java -jar some-service.jar --param1 val1 ....
User=some-user
UFO just landed and posted this here
в скриптах в init.d можно через start-stop-daemon указывать под кем запускаться.
Да, это вариант, но не всем нравится systemd.
А добавить su -c в init.d script можно?
Да, там это уже сделано. Проблема в том, что владелец скрипта (скрипт это и есть jar-файл) пользователь, а скрипт запускается с привилегиями root.
А run_user определяется по владельцу jar-файла:
start-stop-daemon --start --quiet \
--chuid "$run_user" \
А run_user определяется по владельцу jar-файла:
[[ $(id -u) == "0" ]] && run_user=$(ls -ld "$jarfile" | awk '{print $3}')
UFO just landed and posted this here
Sign up to leave a comment.
Spring Boot — проблема с безопасностью исполняемых jar файлов запускаемых как init.d сервис