1) systemd-inhibit таким образом работает с пробелами. Конечно часто пишут, то что eval небезопасен, но возможно его именно для подобных задач и создавали?))
2) В данном случае, эмпирическим путём проверил безопасность eval в данном месте, на примере
В чём заключается смысл, мы создаём переменную qwe помещая в неё ls, asd="eval \"$qwe\"", то есть аналог того, что в пр, $asd и enter в терминале и $asd выполняет ls, в данном случае не безопасно, потому что qwe может быть не ls, и выполнит более вредоносную команду. Но, PW_INHIBIT_SLR="eval systemd-inhibit --mode=block --who=ru.linux_gaming.PortProton --why=\"$qwe\"" , qwe с ls и при $PW_INHIBIT_SLR не выполнит ls, потому что eval чётко привязан к systemd-inhibit , a $qwe не сможет выполнить какую-то команду, потому что это всего лишь аргумент --why= у systemd-inhibit
1) systemd-inhibit таким образом работает с пробелами. Конечно часто пишут, то что eval небезопасен, но возможно его именно для подобных задач и создавали?)) 2) В данном случае, эмпирическим путём проверил безопасность eval в данном месте, на примере
В чём заключается смысл, мы создаём переменную qwe помещая в неё ls, asd="eval \"$qwe\"", то есть аналог того, что в пр, $asd и enter в терминале и $asd выполняет ls, в данном случае не безопасно, потому что qwe может быть не ls, и выполнит более вредоносную команду. Но, PW_INHIBIT_SLR="eval systemd-inhibit --mode=block --who=ru.linux_gaming.PortProton --why=\"$qwe\"" , qwe с ls и при $PW_INHIBIT_SLR не выполнит ls, потому что eval чётко привязан к systemd-inhibit , a $qwe не сможет выполнить какую-то команду, потому что это всего лишь аргумент --why= у systemd-inhibit