gpg-agent говорит, что агент существует, но gpg говорит, что агент не существует?

Я борюсь с некоторыми проблемами во время написания скриптов bash на коробке Debian 6.0.6. У меня есть скрипт, который выполняет пакет операций и хочет убедиться, что gpg-agent доступен, прежде чем он попытается продолжить.

Поскольку gpg-agent не будет предпринимать никаких действий и вернет успех, если он запущен, когда он уже запущен, обеспечить присутствие агента так же просто, как:

eval $(gpg-agent --daemon)

gpg-agent начать или сообщит:

gpg-agent[21927]: a gpg-agent is already running - not starting a new one

и вернуть 0 (успех), если он уже запущен.

Проблема возникает, когда агент уже запущен в другом сеансе. gpg-agent говорит, что уже работает... но gpg тогда он сам утверждает, что он недоступен.

$ gpg-agent --version
gpg-agent (GnuPG) 2.0.19
libgcrypt 1.5.0
$ gpg --version
gpg (GnuPG) 1.4.13

$ eval $(gpg-agent --daemon)
gpg-agent[21927]: a gpg-agent is already running - not starting a new one
$ gpg -d demo-file.asc
gpg: gpg-agent is not available in this session

Это оставляет меня разочарованным и смущенным. Похоже, что gpg-agent обнаруживает агента по-другому, чтобы показать себя. Хуже, gpg не предлагает способа спросить, доступен ли агент с помощью сценариев, так же как он предпочитает беззвучно игнорировать получателей с неиспользуемыми ключами и по-прежнему возвращать успех, поэтому очень трудно обнаружить эту проблему перед началом пакета. Я не хочу разбираться с выводом gpg по ряду причин.

Вы можете воспроизвести это, убедившись, что у вас нет запущенного gpg-агента или у вас есть GPG_AGENT_INFO установить, затем в одном терминале работает eval $(gpg-agent --daemon) и в другом терминале работает выше. Вы заметите, что gpg-agent говорит, что он уже запущен, но gpg не удается подключиться к агенту.

Идеи?

ОБНОВЛЕНИЕ: gpg-agent обнаруживает другого агента путем поиска файла сокета в известном месте и записи в него для проверки на живучесть, согласно этому strace:

socket(PF_FILE, SOCK_STREAM, 0)         = 5
connect(5, {sa_family=AF_FILE, sun_path="/home/craig/.gnupg/S.gpg-agent"}, 32) = 0
fcntl(5, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(5, F_GETFL)                       = 0x2 (flags O_RDWR)
select(6, [5], NULL, NULL, {0, 0})      = 1 (in [5], left {0, 0})
read(5, "OK Pleased to meet you, process "..., 1002) = 38
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f41a3e61000
write(2, "gpg-agent: gpg-agent running and"..., 43gpg-agent: gpg-agent running and available
) = 43

в то время как GnuPG, кажется, смотрит только на окружающую среду, игнорируя известное расположение сокетов. В common/simple-pwquery.c:

/* Try to open a connection to the agent, send all options and return
   the file descriptor for the connection.  Return -1 in case of
   error. */
static int
agent_open (int *rfd)
{
  int rc;
  int fd;
  char *infostr, *p;
  struct sockaddr_un client_addr;
  size_t len;
  int prot;
  char line[200];
  int nread;

  *rfd = -1;
  infostr = getenv ( "GPG_AGENT_INFO" );
  if ( !infostr || !*infostr )
    infostr = default_gpg_agent_info;
  if ( !infostr || !*infostr )
    {
#ifdef SPWQ_USE_LOGGING
      log_error (_("gpg-agent is not available in this session\n"));
#endif
      return SPWQ_NO_AGENT;
    }
    /* blah blah blah truncated blah */
}

Я на самом деле не хочу убивать агента, просто чтобы убедиться, что могу запустить его снова, и нет стандартного места, где агент пользователя мог бы написать файл среды. Хуже, я даже не могу проверить на наличие GPG_AGENT_INFO в среде, поскольку это может относиться к устаревшему (мертвому) агенту, который с тех пор был заменен... и ни gpg ни gpg-agent укажите параметр командной строки для проверки связи с агентом и возврата true, если все в порядке.

4 ответа

  1. Вы можете проверить код выхода gpg-connect-agent /bye
  2. Вы можете проверить, существует ли сокет, указанный в $GPG_AGENT_INFO. Этого должно быть достаточно, но вы также можете проверить с помощью fuser или lsof, является ли процесс, указанный в $GPG_AGENT_INFO, процессом, который открыл сокет. И если вы хотите быть действительно исчерпывающим, вы также можете проверить, является ли /proc/$PID/exe ссылкой на /usr/bin/gpg-agent (или что-то еще).

Основная версия запущенного агента gpg - 2. Вы должны вызвать gpg2, а не gpg, как ответили здесь: https://unix.stackexchange.com/questions/231386/how-to-make-gpg-find-gpg-agent

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

if ! test -v GPG_AGENT_INFO; then
    if gpg-agent 2>/dev/null; then
        if test -e /tmp/.gpg-agent-$USER/env; then
            . /tmp/.gpg-agent-$USER/env
        elif test -e ~/.gpg-agent-info; then
            . ~/.gpg-agent-info
        else
            echo 'A gpg agent is running, but we cannot find its socket info because'
            echo 'the GPG_AGENT_INFO env var is not set and gpg agent info has not been'
            echo 'written to any expected location. Cannot continue. Please report this'
            echo 'issue for investigation.'
            exit 5
        fi
    else
        mkdir /tmp/.gpg-agent-$USER
        chmod 700 /tmp/.gpg-agent-$USER
        gpg-agent --daemon --write-env-file /tmp/.gpg-agent-$USER/env
        . /tmp/.gpg-agent-$USER/env
    fi
    # The env file doesn't include an export statement
    export GPG_AGENT_INFO
else
    if ! gpg-agent 2>/dev/null; then
        echo 'GPG_AGENT_INFO is set, but cannot connect to the agent.'
        echo 'Unsure how to proceed, so aborting execution. Please report this'
        echo 'issue for investigation.'
        exit 5
    fi
fi

Это проверит на GPG_AGENT_INFO в среде, и если она установлена, убедитесь, что gpg-agent действительно запущен. (Я еще не уверен, как это взаимодействует с другими реализациями gpg-agent, такими как агент GNOME). Если информация об агенте установлена, но агент не работает, он не знает, как справиться, и сдается.

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

Если агент не запущен и информация об агенте не установлена, он запускает агент, записывает файл env в приватное местоположение и продолжает работу.

Сказать, что я недоволен этим ужасным, враждебным к пользователю и ненадежным хакером, - преуменьшение.

Это очень удивительно, что gpg, инструмент безопасности / шифрования, проигнорирует аргументы и продолжит работу. --use-agent должна быть фатальной ошибкой, если агент не работает, по крайней мере, опционально, как указание -r с неверным получателем должна быть ошибка, а не игнорироваться. Дело в том, что gpg находит своего агента другой путь к gpg-agent Команда сбивает с толку.

В моей системе Ubuntu gpg-agent настроен на запись своего файла среды ~/.gnupg/gpg-agent-info-$(hostname) (что сделано /etc/X11/Xsession.d/90gpg-agent). Если ваша система этого не делает, вы можете изменить способ запуска агента для записи файла среды в хорошо известном месте, которое впоследствии можно будет найти. Например:

$ gpg-agent --daemon --write-env-file="$HOME/.gnupg/gpg-agent-info"
$ source ~/.gnupg/gpg-agent-info
Другие вопросы по тегам