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
