[pkg-gnupg-maint] Bug#836772: Bug#836772: gnupg: unable to sign anyone's keys

[Ramakrishnan Muthukrishnan]

Hi Dan--

Thanks for the note. Please see below.

On Wed, Sep 7, 2016, at 02:07 AM, Daniel Kahn Gillmor wrote:
> 
> On Tue 2016-09-06 05:12:07 -0400, Ramakrishnan Muthukrishnan wrote:
> > On Tue, Sep 6, 2016, at 12:47 PM, Daniel Kahn Gillmor wrote:
> >> If it still fails, what happens when you expand the permissions on your
> >> terminal before doing an su ?  For example, if your Keyring Account is
> >> named "keyring-account" and you have the acl package installed, you
> >> might try a wrapper like this:
> >> 
> >>     #!/bin/sh
> >>     setfacl -m u:keyring-account:rw $(tty)
> >>     su - keyring-account
> >>     setfacl -x u:keyring-account $(tty)
> >
> > Ok, I tried that. The first setfacl command is returning an error: 
> >
> >   "setfacl: /dev/pts/1: Operation not supported"
> >
> > After logging in, it had the same behaviour as before, failing with
> > Permission denied message. I am guessing the setfacl failed and hence it
> > didn't have any effect.
> 
> hm, right, it looks like devpts doesn't support acls:
> 
>   https://serverfault.com/questions/398659/acl-on-dev-pts/398683
>   https://lwn.net/Articles/121773/
> 
> That's a shame.  what about changing the group membership of the tty
> before triggering the su - ?
> 
>     chgrp $(getent passwd keyring-user | cut -f4 -d:) $(tty)

Hmm. That command errored out with a "permission denied". But the second
one succeeded.  

>     chmod g+rw $(tty)

As 'root', I added the keyring-user into the group 'tty' and then the
signing worked just fine.

> to be clear: these tests are all diagnostics just to make sure we
> understand the problem.

Yes, totally understand and I am very glad to help make gpg and
associated tools in all situations for all users. It is very important.

> I'd like in general to come up with a more useful configuration that
> meets your goals.
> 
> To be clear: i think you're doing these operations separately because
> you don't want to expose your secret key material to the Main Account.
> 
> Is that right?

Yes, that's correct. This is a work computer that I occasionally use
only during travel and I was concerned that any non-free binaries that I
may have to run at work does dubious stuff on these important files.
While one could probably find holes in this argument, I thought it is a
good first step to protect the keys via the good old Unix userid based
access control mechanisms.

> If so, have you considered launching a gpg-agent process from your
> Keyring Account and exporting an "extra socket" that is accessible by
> your Main Account?  Would an arrangement like that meet your needs?

I didn't know about exporting the extra socket. Still reading up on the
gpg2 and associated programs.

I think it is perfectly fine with the setup where I can switch to
virtual terminal and log into the acccount. 

> > I just tried logging into the machine from the terminal (with the
> > pinentry-program set to the ncurses version setup in the conf file) and
> > that worked perfectly. So, this "bug" is not blocking me from signing
> > the keys.
> 
> OK, that's good to hear :)

Thanks again. :) I am very glad to help with the package in whatever
small way I can.

--
  Ramakrishnan