| Message ID | 20200507231147.27025-1-James.Bottomley@HansenPartnership.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | TPM 2.0 trusted keys with attached policy | expand |
On Thu, 2020-05-07 at 16:11 -0700, James Bottomley wrote: > This is a respin on v8 to make the encoder selectable and address > David's comments. The trusted key part hasn't changed except to add a > now necessary select for ASN1_ENCODER to patch 4 and the changelog of > patch 6 has been updated to correct the cut and paste error in the > keyctl statement. > > General cover letter: > > This patch updates the trusted key code to export keys in the ASN.1 > format used by current TPM key tools (openssl_tpm2_engine and > openconnect). It also simplifies the use of policy with keys because > the ASN.1 format is designed to carry a description of how to > construct the policy, with the result that simple policies (like > authorization and PCR locking) can now be constructed and used in the > kernel, bringing the TPM 2.0 policy use into line with how TPM 1.2 > works. > > The key format is designed to be compatible with our two openssl > engine implementations as well as with the format used by openconnect. > I've added seal/unseal to my engine so I can use it for > interoperability testing and I'll later use this for sealed symmetric > keys via engine: > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/ > > James I'm compiling now kernel with all series included. Kind of checking if I could just take the whole series. Let see. In all cases I want the style errors in 3/8 to be fixes with a helper but maybe better to hold before sending anything. Possibly that is all needed I'll just carve that patch myself. Please don't do anything for the moment. /Jarkko
On Thu, 2020-05-14 at 17:31 +0300, Jarkko Sakkinen wrote: > I'm compiling now kernel with all series included. > > Kind of checking if I could just take the whole series. Let see. > > In all cases I want the style errors in 3/8 to be fixes with a helper > but maybe better to hold before sending anything. Possibly that is all > needed I'll just carve that patch myself. > > Please don't do anything for the moment. This is what I tried first (with the full series applied): #!/bin/sh die() { keyctl clear @u ./tpm2-flush --all-transient exit $1 } KEYHANDLE=$(./tpm2-root-key || die 1) KEYID=$(keyctl add trusted kmk "new 32 keyhandle=$KEYHANDLE hash=sha256" @u || die 1) echo "$KEYID ($KEYHANDLE)" keyctl pipe $KEYID > blob.hex || die 1 keyctl clear @u || die 1 echo "Import key from blob" keyctl add trusted kmk "load `cat blob.hex` keyhandle=$KEYHANDLE" @u || die 1 die 0 Result: sudo ./keyctl-smoke.sh 566201053 (0x80000000) keyctl_read_alloc: Permission denied Any ideas what I might have done wrong? Have not tried auth value yet but afaik the above should fully test import and export. Uses tpm2-scripts: https://github.com/jsakkine-intel/tpm2-scripts I'll probably move these to git.infradead.org because I don't like really like at all Github and my kernel tree is there anyway. /Jarkko
On Fri, 2020-05-15 at 05:22 +0300, Jarkko Sakkinen wrote: > On Thu, 2020-05-14 at 17:31 +0300, Jarkko Sakkinen wrote: > > I'm compiling now kernel with all series included. > > > > Kind of checking if I could just take the whole series. Let see. > > > > In all cases I want the style errors in 3/8 to be fixes with a > > helper > > but maybe better to hold before sending anything. Possibly that is > > all > > needed I'll just carve that patch myself. > > > > Please don't do anything for the moment. > > This is what I tried first (with the full series applied): > > #!/bin/sh > > die() > { > keyctl clear @u > ./tpm2-flush --all-transient > exit $1 > } > > KEYHANDLE=$(./tpm2-root-key || die 1) > KEYID=$(keyctl add trusted kmk "new 32 keyhandle=$KEYHANDLE > hash=sha256" @u || die 1) > > echo "$KEYID ($KEYHANDLE)" > > keyctl pipe $KEYID > blob.hex || die 1 > keyctl clear @u || die 1 > > echo "Import key from blob" > > keyctl add trusted kmk "load `cat blob.hex` keyhandle=$KEYHANDLE" @u > || die 1 > > die 0 > > Result: > > sudo ./keyctl-smoke.sh > 566201053 (0x80000000) > keyctl_read_alloc: Permission denied Well, it's clearly failing in keyctl pipe I do confess to never having tested a volatile primary, but I just did so and it works for me. I will also add the keyhandle in the load isn't necessary, because it should be in the blob, but there should also be no harm (just tested). However, I don't have keyctl_read_alloc in my tree, so it may be an incompatibility with another patch set. What's your base and what other patches do you have applied? James > Any ideas what I might have done wrong? Have not tried auth value yet > but afaik the above should fully test import and export. > > Uses tpm2-scripts: > > https://github.com/jsakkine-intel/tpm2-scripts > > I'll probably move these to git.infradead.org because I don't like > really like at all Github and my kernel tree is there anyway. > > /Jarkko >
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: > > On Thu, 2020-05-14 at 17:31 +0300, Jarkko Sakkinen wrote: > > > I'm compiling now kernel with all series included. > > > > > > Kind of checking if I could just take the whole series. Let see. > > > > > > In all cases I want the style errors in 3/8 to be fixes with a > > > helper > > > but maybe better to hold before sending anything. Possibly that is > > > all > > > needed I'll just carve that patch myself. > > > > > > Please don't do anything for the moment. > > > > This is what I tried first (with the full series applied): > > > > #!/bin/sh > > > > die() > > { > > keyctl clear @u > > ./tpm2-flush --all-transient > > exit $1 > > } > > > > KEYHANDLE=$(./tpm2-root-key || die 1) > > KEYID=$(keyctl add trusted kmk "new 32 keyhandle=$KEYHANDLE > > hash=sha256" @u || die 1) > > > > echo "$KEYID ($KEYHANDLE)" > > > > keyctl pipe $KEYID > blob.hex || die 1 > > keyctl clear @u || die 1 > > > > echo "Import key from blob" > > > > keyctl add trusted kmk "load `cat blob.hex` keyhandle=$KEYHANDLE" @u > > || die 1 > > > > die 0 > > > > Result: > > > > sudo ./keyctl-smoke.sh > > 566201053 (0x80000000) > > keyctl_read_alloc: Permission denied > > Well, it's clearly failing in keyctl pipe > > I do confess to never having tested a volatile primary, but I just did > so and it works for me. I will also add the keyhandle in the load > isn't necessary, because it should be in the blob, but there should > also be no harm (just tested). > > However, I don't have keyctl_read_alloc in my tree, so it may be an > incompatibility with another patch set. What's your base and what > other patches do you have applied? http://git.infradead.org/users/jjs/linux-tpmdd.git Or exactly: git://git.infradead.org/users/jjs/linux-tpmdd.git (master) /Jarkko
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: >> > On Thu, 2020-05-14 at 17:31 +0300, Jarkko Sakkinen wrote: >> > > I'm compiling now kernel with all series included. >> > > >> > > Kind of checking if I could just take the whole series. Let see. >> > > >> > > In all cases I want the style errors in 3/8 to be fixes with a >> > > helper >> > > but maybe better to hold before sending anything. Possibly that is >> > > all >> > > needed I'll just carve that patch myself. >> > > >> > > Please don't do anything for the moment. >> > >> > This is what I tried first (with the full series applied): >> > >> > #!/bin/sh >> > >> > die() >> > { >> > keyctl clear @u >> > ./tpm2-flush --all-transient >> > exit $1 >> > } >> > >> > KEYHANDLE=$(./tpm2-root-key || die 1) >> > KEYID=$(keyctl add trusted kmk "new 32 keyhandle=$KEYHANDLE >> > hash=sha256" @u || die 1) >> > >> > echo "$KEYID ($KEYHANDLE)" >> > >> > keyctl pipe $KEYID > blob.hex || die 1 >> > keyctl clear @u || die 1 >> > >> > echo "Import key from blob" >> > >> > keyctl add trusted kmk "load `cat blob.hex` keyhandle=$KEYHANDLE" @u >> > || die 1 >> > >> > die 0 >> > >> > Result: >> > >> > sudo ./keyctl-smoke.sh >> > 566201053 (0x80000000) >> > keyctl_read_alloc: Permission denied >> >> Well, it's clearly failing in keyctl pipe >> >> I do confess to never having tested a volatile primary, but I just did >> so and it works for me. I will also add the keyhandle in the load >> isn't necessary, because it should be in the blob, but there should >> also be no harm (just tested). >> >> However, I don't have keyctl_read_alloc in my tree, so it may be an >> incompatibility with another patch set. What's your base and what >> other patches do you have applied? > >http://git.infradead.org/users/jjs/linux-tpmdd.git > >Or exactly: > >git://git.infradead.org/users/jjs/linux-tpmdd.git (master) > >/Jarkko > keyctl_read_alloc is in the userspace keyctl program, right? git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git
On Fri, 2020-05-15 at 02:30 -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: [...] > > > However, I don't have keyctl_read_alloc in my tree, so it may be > > > an incompatibility with another patch set. What's your base and > > > what other patches do you have applied? > > > > http://git.infradead.org/users/jjs/linux-tpmdd.git > > > > Or exactly: > > > > git://git.infradead.org/users/jjs/linux-tpmdd.git (master) > > > > /Jarkko > > > > keyctl_read_alloc is in the userspace keyctl program, right? > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git Hm, right thanks! I just confirmed that linux-tpmdd.git with these patches applied still works for me. I'm using the keyctl in debian testing, which identifies itself as version 1.6-6 I'll try building from git. James
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: >> > On Thu, 2020-05-14 at 17:31 +0300, Jarkko Sakkinen wrote: >> > > I'm compiling now kernel with all series included. >> > > >> > > Kind of checking if I could just take the whole series. Let see. >> > > >> > > In all cases I want the style errors in 3/8 to be fixes with a >> > > helper >> > > but maybe better to hold before sending anything. Possibly that is >> > > all >> > > needed I'll just carve that patch myself. >> > > >> > > Please don't do anything for the moment. >> > >> > This is what I tried first (with the full series applied): >> > >> > #!/bin/sh >> > >> > die() >> > { >> > keyctl clear @u >> > ./tpm2-flush --all-transient >> > exit $1 >> > } >> > >> > KEYHANDLE=$(./tpm2-root-key || die 1) >> > KEYID=$(keyctl add trusted kmk "new 32 keyhandle=$KEYHANDLE >> > hash=sha256" @u || die 1) >> > >> > echo "$KEYID ($KEYHANDLE)" >> > >> > keyctl pipe $KEYID > blob.hex || die 1 >> > keyctl clear @u || die 1 >> > >> > echo "Import key from blob" >> > >> > keyctl add trusted kmk "load `cat blob.hex` keyhandle=$KEYHANDLE" @u >> > || die 1 >> > >> > die 0 >> > >> > Result: >> > >> > 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. >> >> Well, it's clearly failing in keyctl pipe >> >> I do confess to never having tested a volatile primary, but I just did >> so and it works for me. I will also add the keyhandle in the load >> isn't necessary, because it should be in the blob, but there should >> also be no harm (just tested). >> >> However, I don't have keyctl_read_alloc in my tree, so it may be an >> incompatibility with another patch set. What's your base and what >> other patches do you have applied? > >http://git.infradead.org/users/jjs/linux-tpmdd.git > >Or exactly: > >git://git.infradead.org/users/jjs/linux-tpmdd.git (master) > >/Jarkko >
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. James
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. Doing "sudo su -" has always been required. "su -" must set some environment variables. This isn't a problem for dracut as it is running as root. Mimi
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. James
> On May 15, 2020, at 4:10 PM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > I think that means the solution is not to run the smoke test under sudo > but to do sudo -s and then run it. > > James How about "sudo -i": https://askubuntu.com/questions/376199/sudo-su-vs-sudo-i-vs-sudo-bin-bash-when-does-it-matter-which-is-used Mehmet
On Fri, 2020-05-15 at 21:03 +0000, Kayaalp, Mehmet wrote: > > On May 15, 2020, at 4:10 PM, James Bottomley <James.Bottomley@hanse > > npartnership.com> wrote: > > > > I think that means the solution is not to run the smoke test under > > sudo > > but to do sudo -s and then run it. > > > > James > > How about "sudo -i": > > https://askubuntu.com/questions/376199/sudo-su-vs-sudo-i-vs-sudo-bin- > bash-when-does-it-matter-which-is-used Actually, no that doesn't work either: jejb@testdeb> sudo -i keyctl list @s 1 key in keyring: 1041514063: ---lswrv 1000 65534 keyring: _uid.1000 I suspect this might be a very subtle bug to do with when you get a new session keyring. James
On Fri, 2020-05-15 at 15:19 -0700, James Bottomley wrote: > On Fri, 2020-05-15 at 21:03 +0000, Kayaalp, Mehmet wrote: > > > On May 15, 2020, at 4:10 PM, James Bottomley <James.Bottomley@han > > > se > > > npartnership.com> wrote: > > > > > > I think that means the solution is not to run the smoke test > > > under sudo but to do sudo -s and then run it. > > > > > > James > > > > How about "sudo -i": > > > > https://askubuntu.com/questions/376199/sudo-su-vs-sudo-i-vs-sudo- > > bin-bash-when-does-it-matter-which-is-used > > Actually, no that doesn't work either: > > jejb@testdeb> sudo -i keyctl list @s > 1 key in keyring: > 1041514063: ---lswrv 1000 65534 keyring: _uid.1000 > > I suspect this might be a very subtle bug to do with when you get a > new session keyring. It turns out to be incredibly subtle, but I'm not sure if it's a bug or not. the util-linux sudo like commands have special pam profiles /etc/pam.d/su-l /etc/pam.d/runuser-l These special profiles call pam_keyinit.so with flags to install a new session keyring. sudo doesn't have this, so it never, on its own, even when called with -i or -s, installs a new session keyring. This does strike me as a bizarre oversight which leads directly to this weird keyctl pipe behaviour. I'm also not sure the keyctl pipe behaviour is correct: why should keyctl pipe deny access to root to read a key just because it's in a different session keyring? It defintely seems intentional, because if I create a key as a non root user and try to print it by id as root I get EPERM. The weirdest behaviour, though seems to be keyctl: keyctl add ... @u will add to the session keyrings of the actual uid regardless of what session keyring the creator actually has, which is why keyctl add ... @u works under sudo but you get EPERM back trying to pipe it by id. James
On Fri, 2020-05-15 at 02:30 -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: > > > > On Thu, 2020-05-14 at 17:31 +0300, Jarkko Sakkinen wrote: > > > > > I'm compiling now kernel with all series included. > > > > > > > > > > Kind of checking if I could just take the whole series. Let see. > > > > > > > > > > In all cases I want the style errors in 3/8 to be fixes with a > > > > > helper > > > > > but maybe better to hold before sending anything. Possibly that is > > > > > all > > > > > needed I'll just carve that patch myself. > > > > > > > > > > Please don't do anything for the moment. > > > > > > > > This is what I tried first (with the full series applied): > > > > > > > > #!/bin/sh > > > > > > > > die() > > > > { > > > > keyctl clear @u > > > > ./tpm2-flush --all-transient > > > > exit $1 > > > > } > > > > > > > > KEYHANDLE=$(./tpm2-root-key || die 1) > > > > KEYID=$(keyctl add trusted kmk "new 32 keyhandle=$KEYHANDLE > > > > hash=sha256" @u || die 1) > > > > > > > > echo "$KEYID ($KEYHANDLE)" > > > > > > > > keyctl pipe $KEYID > blob.hex || die 1 > > > > keyctl clear @u || die 1 > > > > > > > > echo "Import key from blob" > > > > > > > > keyctl add trusted kmk "load `cat blob.hex` keyhandle=$KEYHANDLE" @u > > > > > > die 1 > > > > > > > > die 0 > > > > > > > > Result: > > > > > > > > sudo ./keyctl-smoke.sh > > > > 566201053 (0x80000000) > > > > keyctl_read_alloc: Permission denied > > > > > > Well, it's clearly failing in keyctl pipe > > > > > > I do confess to never having tested a volatile primary, but I just did > > > so and it works for me. I will also add the keyhandle in the load > > > isn't necessary, because it should be in the blob, but there should > > > also be no harm (just tested). > > > > > > However, I don't have keyctl_read_alloc in my tree, so it may be an > > > incompatibility with another patch set. What's your base and what > > > other patches do you have applied? > > > > http://git.infradead.org/users/jjs/linux-tpmdd.git > > > > Or exactly: > > > > git://git.infradead.org/users/jjs/linux-tpmdd.git (master) > > > > /Jarkko > > > > keyctl_read_alloc is in the userspace keyctl program, right? > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git Yes. /Jarkko
On Fri, 2020-05-15 at 11:48 -0700, James Bottomley wrote: > On Fri, 2020-05-15 at 02:30 -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: > [...] > > > > However, I don't have keyctl_read_alloc in my tree, so it may be > > > > an incompatibility with another patch set. What's your base and > > > > what other patches do you have applied? > > > > > > http://git.infradead.org/users/jjs/linux-tpmdd.git > > > > > > Or exactly: > > > > > > git://git.infradead.org/users/jjs/linux-tpmdd.git (master) > > > > > > /Jarkko > > > > > > > keyctl_read_alloc is in the userspace keyctl program, right? > > > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git > > Hm, right thanks! I just confirmed that linux-tpmdd.git with these > patches applied still works for me. I'm using the keyctl in debian > testing, which identifies itself as version 1.6-6 > > I'll try building from git. > James Can you run the same exact command sequence that I posted? /Jarkko
On Fri, 2020-05-15 at 12:17 -0700, Jerry Snitselaar 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. Can confirm these results with NUC7PJYH (Gemini Lake). /Jarkko
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
On Fri, 2020-05-15 at 16:23 -0700, James Bottomley wrote: > On Fri, 2020-05-15 at 15:19 -0700, James Bottomley wrote: > > On Fri, 2020-05-15 at 21:03 +0000, Kayaalp, Mehmet wrote: > > > > On May 15, 2020, at 4:10 PM, James Bottomley <James.Bottomley@han > > > > se > > > > npartnership.com> wrote: > > > > > > > > I think that means the solution is not to run the smoke test > > > > under sudo but to do sudo -s and then run it. > > > > > > > > James > > > > > > How about "sudo -i": > > > > > > https://askubuntu.com/questions/376199/sudo-su-vs-sudo-i-vs-sudo- > > > bin-bash-when-does-it-matter-which-is-used > > > > Actually, no that doesn't work either: > > > > jejb@testdeb> sudo -i keyctl list @s > > 1 key in keyring: > > 1041514063: ---lswrv 1000 65534 keyring: _uid.1000 > > > > I suspect this might be a very subtle bug to do with when you get a > > new session keyring. > > It turns out to be incredibly subtle, but I'm not sure if it's a bug or > not. the util-linux sudo like commands have special pam profiles > > /etc/pam.d/su-l > /etc/pam.d/runuser-l > > These special profiles call pam_keyinit.so with flags to install a new > session keyring. sudo doesn't have this, so it never, on its own, even > when called with -i or -s, installs a new session keyring. This does > strike me as a bizarre oversight which leads directly to this weird > keyctl pipe behaviour. > > I'm also not sure the keyctl pipe behaviour is correct: why should > keyctl pipe deny access to root to read a key just because it's in a > different session keyring? It defintely seems intentional, because if > I create a key as a non root user and try to print it by id as root I > get EPERM. > > The weirdest behaviour, though seems to be keyctl: keyctl add ... @u > will add to the session keyrings of the actual uid regardless of what > session keyring the creator actually has, which is why keyctl add ... > @u works under sudo but you get EPERM back trying to pipe it by id. > > James I think I construct a low priority bug to kernel bugzilla and link these from l.k.o. Thanks for digging this all up. /Jarkko