Работы Передачи Агента SSH, но что относительно sudo-u имя пользователя никакая оболочка / полномочия? компоновщик

Это должно работать и в ударе и в тире:

if [ ! -e targetfile ] || [ targetfile -nt sourcefile ]
then
    echo "Already up to date"
    exit 0
fi

Однако кажется на желание чего-то, любят, делают.

В bash Вы могли даже записать
make -f- <<<'targetfile: sourcefile ;' && exit 0,
но <<< синтаксис является конкретным ударом, следовательно Вам нужно
echo "targetfile: sourcefile ;" | make -f- && exit 0
или просто реальный Make-файл.:)

2
23.05.2014, 10:10
3 ответа
[1176171] Единственный способ сделать это - это очень грязный взлом. Я не рекомендую этого делать.

enter image description here

Причина в том, что доступ к вашим SSH-ключам осуществляется через именной разъем. Этот именованный сокет находится в каталоге, принадлежащем вам, и не может быть доступен никому другому. Единственный способ дать доступ другому пользователю - это изменение прав на сокет.[1176610]. Вышеуказанные действия выполняются через расширенные атрибуты файловой системы. Если ваша файловая система [1176611]/tmp[1176612] не поддерживает ACL, то единственный способ сделать это - это [1176613]chmod o+rwx[1176614], и это ужасно небезопасно.

Лучшим решением является исправление того, что мешает вам выполнять эту команду от имени вашего собственного пользователя.[1176176].

6
27.01.2020, 21:52
[1176169] Вы можете использовать [1176606]su имя пользователя [1176607] (суперпользователь), он будет работать как этот пользователь против sudo. Это немного помогает: (не уверен, есть ли еще один в unixstackexchange). [1176608] https://askubuntu.com/questions/376199/sudo-su-vs-sudo-i-vs-sudo-bin-bash-when-does-it-matter-which-is-used

1
27.01.2020, 21:52
[1176177] На a, попробуйте [1176615]ssh other_user@localhost[1176616]. В теории, которая должна переслать ваше соединение ssh-agent снова, позволяя другому_пользователю использовать его. Однако это все равно не сработает с [1176617]/bin/false[1176618] как с оболочкой другого_пользователя.

Я не думаю, что без привилегий root можно обойти эту ограниченную оболочку (и не следует ее использовать).

Из [1176619]man su[1176620]:

Если у целевого пользователя ограниченная оболочка (т.е. поле оболочки этого пользователя в /etc/passwd не указано в /etc/shells), то опция --shell или переменная окружения $SHELL не будут учитываться, если только su не вызывается root.

0
27.01.2020, 21:52

Теги

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