Bug 14627 - gpg-agent prevents login sessions to be closed
Summary: gpg-agent prevents login sessions to be closed
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: High normal
Target Milestone: Mageia 6
Assignee: Colin Guthrie
QA Contact:
URL:
Whiteboard: MGA4TOO MGA5TOO FOR_ERRATA
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-21 00:45 CET by Chris Denice
Modified: 2017-01-17 10:29 CET (History)
5 users (show)

See Also:
Source RPM: gnupg2-2.0.26-3.mga5.src.rpm
CVE:
Status comment:


Attachments

Description Chris Denice 2014-11-21 00:45:37 CET
Description of problem:

Let an user logs into the system (even by shell), then logout. Its login session as displayed by systemd remains stuck in the state "closing"

Here for user test, after 13h of logging out:

loginctl user-status test
test (1001)
            Since: Thu 2014-11-20 09:07:41 CET; 13h ago
            State: closing
         Sessions: c36
             Unit: user-1001.slice
                   ââuser-6qo3N/x+wCJTDjBF/Jpztg@public.gmane.org
                   â ââ30819 /usr/lib/systemd/systemd --user
                   â ââ30820 (sd-pam)
                   ââsession-c36.scope
                     ââ30868 gpg-agent --keep-display --daemon
--write-env-file /home/test 

This is particularly visible when one tries to shutdown the system, this takes quite a time for systemd to shutdown all these sessions in my case.

Cause:

All this is triggered by gpg-agent which is started in every shell in mageia:
Check out /etc/profile.d/gpg-agent.sh and /etc/X11/xinit.d/gpg-agent.

I think this is in absolute a bad idea, and I do not understand why this would be necessary. On the gnupg2 website, one can read at:

https://www.gnupg.org/documentation/manuals/gnupg/Invoking-GPG_002dAGENT.html

"gpg-agent is a daemon to manage secret (private) keys independently from any protocol. It is used as a backend for gpg and gpgsm as well as for a couple of other utilities.

The agent is automatically started on demand by gpg, gpgsm, gpgconf, or gpg-connect-agent. Thus there is no reason to start it manually."

I am not an expert about the usage of gpg-agent, but if there is not objection I would either nuke these two scripts from the package, or more gently change the configuration file in /etc/sysconfig/gnupg2 to have

START_GPGAGENT="no"
START_GPGAGENT_SH="no"

I guess we must fix this before release!

cheers,
chris.




Reproducible: 

Steps to Reproduce:
Chris Denice 2014-11-21 00:45:59 CET

Priority: Normal => release_blocker
Target Milestone: --- => Mageia 5

Comment 1 Bit Twister 2014-11-21 04:34:59 CET
(In reply to Chris Denice from comment #0)


> "gpg-agent is a daemon to manage secret (private) keys independently from
> any protocol. It is used as a backend for gpg and gpgsm as well as for a
> couple of other utilities.
> 
> The agent is automatically started on demand by gpg, gpgsm, gpgconf, or
> gpg-connect-agent. Thus there is no reason to start it manually."
> 
> I am not an expert about the usage of gpg-agent, but if there is not
> objection I would either nuke these two scripts from the package, or more
> gently change the configuration file in /etc/sysconfig/gnupg2 to have


I am not too sure about removing the scripts. I do know disabling Kwallet in the kde configuration menu stops it from being launched.

CC: (none) => junknospam

Comment 2 Chris Denice 2014-11-21 13:20:07 CET
Sure, we should test before.

For instance, we should check that if you switch:
START_GPGAGENT="no"
START_GPGAGENT_SH="no"

in /etc/sysconfig/gnupg2

and restart from scratch, applications using gpg-agent should be able to start it by themselves. If someone tests this, please report here if this work or not!
Comment 3 Chris Denice 2014-12-01 18:53:12 CET
Another side effects of this bug is that systemd never detects idle time; setting 
IdleAction=suspend
IdleActionSec=30min

in /etc/systemd/logind.conf

never suspend the system as gnupg-agent maintains opened sessions even with logged out users. Once these gnupg-agent processes are killed by hand; the system suspends as it should.
Comment 4 Anne Nicolas 2014-12-15 00:26:03 CET
Any update on that bug ?

CC: (none) => ennael1

Comment 5 Chris Denice 2014-12-15 08:11:00 CET
Up to the testing I have done, the following settings in /etc/sysconfig/gnupg2

START_GPGAGENT="no"
START_GPGAGENT_SH="no"

prevent it to start all the time. But that does not fix the issue; as gpg-agent is indeed triggered sometimes by various programs; and never stops afterwards.

The same happens with ssh-agent (which is triggered by opening a ssh session if gpg-agent is not already running).

ssh-agent could be fixed by appending the -t option which gives a timeout delay after which it shuts down. For gpg-agent, I did not find any solution :-/
Comment 6 Olav Vitters 2015-01-04 23:21:36 CET
gpg-agent is started like this so that all terminals and programs can use it (environment variable is shared for all programs in that session).

Colin, thoughts?

CC: (none) => mageia, olav

Comment 7 Colin Guthrie 2015-01-05 10:17:12 CET
Well, these days the comms sockets used by gpg (and ssh) agents could be standardised in /run/user/$UID/ folder and thus not need any direct env vars (the paths could be baked into any client programs).

Then those socket paths could have systemd (user) units and then be made socket activatable and have the timeout option to kill themselves after inactivity.

This would be the best plan going forward but it'll take some time to achieve this.

As a transitional phase we could:

1. Add the env var to a drop in file in /usr/lib/systemd/system/user@.service.d/gpg-agent.conf (and ssh-agent.conf) with:

[Service]
Environment=GPG_AGENT_INFO=/run/user/%I/gpg-agent

Then teach gpg-agent to accept a socket path as an argument and be socket activatable (will need patching).

Then write appropriate systemd user units that will live in /usr/lib/systemd/user/gpg-agent.{socket,service}


The patches should be fairly simple (someone may have written them already) and we can then kill off all the other methods of starting.

I may have missed some corner case of course, but I think this make sense going forward.
Comment 8 Anne Nicolas 2015-01-22 08:47:26 CET
Colin, any input on this one? were you able to commit those patches ?
Comment 9 Chris Denice 2015-02-04 15:36:52 CET
Up to the fact that this bug moved some dirt from under to over the carpet; it will be directly affecting only a few users using automatic suspend and/or machine having a lot of connected users.

Maybe that is fine to remove the release critical tag if we mention it in the mga5 errata, and we may target mga6 for a complete carpet hoovering?
Comment 10 Colin Guthrie 2015-02-05 21:32:29 CET
Yeah I think we can remove this. It's already an issue under MGA4 anyway, so no worse than before :)

In MGA6 we will likely switch to a user bus, have predicable paths for SSH/GPG agent sockets and can teach them to exit after idle time outs (and be socket activatable). This will make things much nicer generally.

Hope the bug changes are agreed with (it would be nice to fix now, but sadly too much to do generally before MGA5 :()

Severity: critical => normal
Assignee: bugsquad => mageia
Priority: release_blocker => High

Chris Denice 2015-03-19 17:12:05 CET

Blocks: (none) => 15527

Samuel Verschelde 2015-06-02 10:09:51 CEST

Target Milestone: Mageia 5 => Mageia 6
Whiteboard: (none) => MGA4TOO MGA5TOO FOR_ERRATA

Comment 11 Olav Vitters 2015-12-16 23:03:19 CET
Arch has a unit file for this. It is bit nasty in that it just kills any gpg-agent when it should stop.

https://wiki.archlinux.org/index.php/GnuPG#Start_gpg-agent_with_systemd_user
Comment 12 Chris Denice 2016-05-06 13:27:10 CEST
Thanks for the info Olav.

I am starting to look at it in order to migrate both ssh-agent and gpg-agent to systemd user services. If anyone has some comments or other links to read, please post-it here, I am in Terra-incognita :)

Cheers.
Comment 13 Chris Denice 2016-06-01 19:47:52 CEST
Just pushed gnupg2-2.0.30-3.mga6 on Cauldron which is only based on systemd --user service.

It seems to behave nicely, switches on with pam systemd settings, i.e. on login and X, but not on remote ssh. It also switches off when the user logs out and the associated session can now close.

This is not yet the end of the story as the same would need to be done for ssh-agent. Also some work has to be done on keychain as, currently, it can trigger gpg-agent and ssh-agent from /etc/profile.d. I'll have a look as soon as I can. In the meanwhile, please report here if gnupg-agent fails.

Cheers,
Chris.
Comment 14 Colin Guthrie 2016-06-07 10:39:30 CEST
(In reply to Chris Denice from comment #13)
> Just pushed gnupg2-2.0.30-3.mga6 on Cauldron which is only based on systemd
> --user service.
> 
> It seems to behave nicely, switches on with pam systemd settings, i.e. on
> login and X, but not on remote ssh. It also switches off when the user logs
> out and the associated session can now close.

Excellent! I've been hoping this would happen sooner rather than later! Excellent work!

> This is not yet the end of the story as the same would need to be done for
> ssh-agent. Also some work has to be done on keychain as, currently, it can
> trigger gpg-agent and ssh-agent from /etc/profile.d. I'll have a look as
> soon as I can. In the meanwhile, please report here if gnupg-agent fails.

Brilliant! Thanks so much!
Comment 15 Chris Denice 2016-06-07 11:42:14 CEST
Thanks Colin :)
Well, to be honest, it is not yet as perfect as it sounds because I did not (yet?) implement activation sockets within systemd as you suggested.

gnupg still uses his old school sockets, but now under the supervision of a --user .service, and thus inherited systemd pam, so at least it is properly killed and started when it should!
Comment 16 Marja Van Waes 2016-07-12 17:26:11 CEST
What is the status of this bug report? Did everything that needed to get fixed, get fixed? (Or can it be closed as fixed for one part, and the rest moved to a new bug report)

CC: (none) => marja11

Comment 17 Chris Denice 2016-07-13 15:12:04 CEST
Yes, that bug is fixed, I am closing it. I am having a look to potential side issues with ssh-agent and now and will open new bug reports if necessary!

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Samuel Verschelde 2017-01-17 10:29:39 CET

Blocks: 15527 => (none)


Note You need to log in before you can comment on or make changes to this bug.