[pkg-gnupg-maint] Bug#950836: Bug#950836: gpg-agent: generator 90gpg-agent and user with no home crontask generate annoying logs

[Daniel Kahn Gillmor]

Control: forwarded 950836 https://dev.gnupg.org/T4866

Hi Laurent--

On Fri 2020-02-07 10:30:59 +0100, lwafflard wrote:
> Every day I receive some logs after cron.daily execution like these
>
> 	systemd[2626]: gpgconf: running /usr/bin/gpg-agent failed (exitcode=2): General error
> 	systemd[2626]: gpgconf: fatal error (exit status 1)
>
> Some cron tasks are executed as «nobody» user, which have no home.

hm, interesting.  I'm not seeing this on some of the test systems i
control that have these packages installed, but maybe i'm not looking at
the right crontab entries.

the files in /etc/cron.daily are executed as root (without privilege
dropping), so presumably some fragment in there is switching users on
its own.  are you using just cron, or anacron as well?

Can you identify the specific crontab entry that is triggering this?

> When executing the script «/usr/lib/systemd/user-environment-generators/90gpg-agent» as nobody, gpgconf break with these lines. To reproduce, you can also as root
>
> 	sudo -u nobody gpgconf --list-options gpg-agent

let's not bring sudo or su into the mix yet here -- the generator and
the test and the specific cron environment seem like they might be 

> Is it possible to update the user-environment-generator ? Redirect stderr would be sufficient ?
>
> 	if [ -n "$(gpgconf --list-options gpg-agent | \
> =>
> 	if [ -n "$(gpgconf --list-options gpg-agent 2>/dev/null | \

a narrower fix might be to have this generator bail if the user's home
directory doesn't exist, right?  but really, gpgconf shouldn't fail
here.

I've reported https://dev.gnupg.org/T4866 upstream to try to clarify the
root cause of the problem.

> Masking globally all gpg services/socket as suggested in /usr/share/doc/gpg-agent/README.Debian is ineffective as generator executed on each new session.

right, i think global masking is not a great idea anyway.  If you're
running a systemd system, it makes more sense for systemd's user session
manager to manage the agent, if one will be running at all.  But if one
can't possibly run (e.g. if gpg-agent can't run if the home directory
doesn't exist) then perhaps we ought to also ought to add a
ConditionPathIsDirectory= and/or ConditionPathIsReadWrite= (see
systemd.unit(5) for details)

          --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20200304/19ae0422/attachment.sig>