On Thu, Dec 1, 2016 at 10:33 AM, Werner Koch via BTS <gnupg@bugs.g10code.com

wrote:

On Wed, Nov 30, 2016 at 10:28 AM, Werner Koch via BTS <
gnupg@bugs.g10code.com> wrote:

On Tue, Nov 29, 2016 at 7:14 PM, Werner Koch via BTS <gnupg@bugs.g10code.com>
wrote:

[...]
thanks for the clarifications, I was 95% there but that rounds it up to the full
picture.

   GNUPGHOME=$(pwd) gpg-agent --daemon -v MYSCRIPT

This starts the agents and runs MYSCRIPT (/bin/sh is nice for testing). After
MYSCRIPT terminates the agent will be terminated within the next minute.

We more or less do that already, and I can confirm it does "terminate the next
minute".
Unfortunately "the next minute" isn't soon enough for my umount.

So I thought for now I might have to rely on an extra call of "gpgconf --kill
dirmngr" to be sure. But I have found that this doesn't end it for me - maybe
related to our custom GNUPGHOME?
It doesn't seem to stop as intended via gpgconf: (neither with nor without
GNUPGHOME):

$ ps axlf | egrep 'gpg|dirmngr'
1 0 18021 1 20 0 176840 6236 - Ssl ? 0:00 dirmngr --
daemon --homedir /tmp/tmped9zl1ip
$ gpgconf --kill dirmngr
$ ps axlf | egrep 'gpg|dirmngr'
1 0 18021 1 20 0 176840 6236 - Ssl ? 0:00 dirmngr --
daemon --homedir /tmp/tmped9zl1ip
$ GNUPGHOME="/tmp/tmped9zl1ip" gpgconf --kill dirmngr
$ ps axlf | egrep 'gpg|dirmngr'
1 0 18021 1 20 0 176840 6236 -
(Also did the same as root without effect, but avoid filling this report only
with logs)

The more obvious but less graceful "sudo killall dirmngr |:" cleans it up.

The reason why your bind mount fails are likely the socket files created there.

via lsof I only found the following to be related (the /dev bind umount is what
fails).
dirmngr 6771 root 1r CHR LG,0x80000 1,9 0t0
11 /tmp/tmptmucmfm0/target/dev/urandom
dirmngr 6771 root 2w CHR W,LG 1,3 0t0
6 /tmp/tmptmucmfm0/target/dev/null
gpg-agent 6776 root 0r CHR LG 1,3 0t0
6 /tmp/tmptmucmfm0/target/dev/null
gpg-agent 6776 root 1w CHR W,LG 1,3 0t0
6 /tmp/tmptmucmfm0/target/dev/null
gpg-agent 6776 root 2w CHR W,LG 1,3 0t0
6 /tmp/tmptmucmfm0/target/dev/null

Not sure, but I'd not expect these are the sockets.
My assumption would be the open /dev/urandom - especially as I found that I only
need to get rid of dirmngr to proceed.

The solution to this are //run/user based sockets. If you create a directory
/run/user/UID gnupg will create a gnupg sub-directory and place the socket
files there.

gpg-conf --list-dirs

can be used to check that.

I created a log based on that check and lsof (the view from inside the chroot):
gpgconf --list-dirs
lsof +fg /dev
gpgconf --kill dirmngr
lsof +fg /dev
pkill gpg-agent
pkill dirmngr
lsof +fg /dev

I'll attach the full log with this post.
You can find there that the agent and dirmngr do not go away on the gpgconf --
kill.
The socket path OTOH looks ok with "agent-socket:/root/.gnupg/S.gpg-agent"

I added this as first command in chroot to give it a try at least:
$ mkdir -p /run/user/$(id -u)
It "worked" in the sense that the dirs changed e.g. from:
dirmngr-socket:/root/.gnupg/S.dirmngr
to
dirmngr-socket:/run/user/0/gnupg/S.dirmngr
But as I expected that did not change the behavior of blocking to umount the /dev

I really think it is not the sockets but e.g. the /dev/urandom it keeps open.

Is there any way to get the agent&dirmngr from "away next minute" to be "away
before exiting the calling command"?

BTW - I wondered if it would be enough if gpg-agent can stay and to only kill
dirmngr - but it seems I need both gone to let me umount.