Re: [PATCH v9 0/8] TPM 2.0 trusted keys with attached policy

["Sakkinen, Jarkko" <jarkko.sakkinen@intel.com>]

On Fri, 2020-05-15 at 13:10 -0700, James Bottomley wrote:
> On Fri, 2020-05-15 at 12:34 -0700, James Bottomley wrote:
> > On Fri, 2020-05-15 at 12:17 -0700, Jerry Snitselaar wrote:
> > > On Fri May 15 20, Jarkko Sakkinen wrote:
> > > > On Thu, May 14, 2020 at 08:44:23PM -0700, James Bottomley wrote:
> > > > > On Fri, 2020-05-15 at 05:22 +0300, Jarkko Sakkinen wrote:
> > 
> > [...]
> > > > > > sudo ./keyctl-smoke.sh
> > > > > > 566201053 (0x80000000)
> > > > > > keyctl_read_alloc: Permission denied
> > > 
> > > I get keyctl_read_alloc -EPERM when I 'sudo su' and try to play
> > > with
> > > keyctl print.
> > > If I 'sudo su -' and then try it works as expected. Also works for
> > > normal user.
> > 
> > OK, I confirm on debian as well.  If I create a key as real root and
> > then try to sudo su keyctl pipe it as an ordinary user, I get EPERM.
> > 
> > It smells like a cockup in real vs effective permissions somewhere in
> > the keyctl handler.
> 
> OK, so the problem is
> 
> sudo keyctl list @s
> 
> Still shows the session keys of the previous user
> 
> that causes sudo keyctl show on a root owned key to fail the
> is_key_possessed() check, returning -EACCESS which gets translated to
> EPERM
> 
> if you do
> 
> sudo su -
> 
> Then keyctl list @s shows the root session keyring and everything works
> 
> I think that means the solution is not to run the smoke test under sudo
> but to do sudo -s and then run it.

Right, makes sense and I can also confirm this in my environment.
Thanks!

/Jarkko