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

[Laurent Wafflard]

Hi Daniel,

> Control: forwarded 950836 https://dev.gnupg.org/T4866
>
> 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?
Just cron

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

«locate» ( 4.6.0+git+20190209-2) seems to be one, the package came with

     /etc/cron.daily/locate              => on line 28     
LOCALUSER="nobody"
                                         => on line 68     call 
updatedb.findutils

     /usr/bin/updatedb.findutils         => on line 295    su $LOCALUSER 
`select_shell $LOCALUSER` -c \

>> 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.
Yes it would be better !
With the Q&D stderr redirect, some logs are not catched by the logcheck 
rules of gpg-agent, we added locally:
     ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: 
Listening on GnuPG cryptographic agent and passphrase cache \(access for 
web browsers\)\.$
     ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: 
Closed GnuPG cryptographic agent and passphrase cache \(access for web 
browsers\)\.$

but it would become useless if gpgconf will be executed only for users 
with existent home.

>
> 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
Thanks for the explanations,
L.Wafflard