Ancestors

Written by Morten Linderud on 2025-01-06 at 22:31

It's been a day and I still don't grok kernel keyring possession.

I'd like a garbage collected anonymouss keyring for my ssh-agent, but it for some reason I can't run add_key own the process keyring 🙃

=> More informations about this toot | More toots from Foxboron@chaos.social

Toot

Written by Morten Linderud on 2025-01-07 at 16:29

Turns out the second you start a goroutine in Go, your loose possession of the session keyring. And then nothing really works?

Do I have to write a key peddler with a locked OS thread that just peddles keys between channels?

=> More informations about this toot | More toots from Foxboron@chaos.social

Descendants

Written by daniel lublin on 2025-01-07 at 18:38

@Foxboron any pointer to code and/or details about this/

=> More informations about this toot | More toots from quitelost@mastodon.social

Written by Morten Linderud on 2025-01-07 at 20:54

@quitelost

A reproducer here. The signal.Notify creates a gorutines that on my end doesn't allow me to look at the keyring anymore.

https://github.com/Foxboron/test-keyring/blob/master/main.go

=> More informations about this toot | More toots from Foxboron@chaos.social

Written by daniel lublin on 2025-01-08 at 07:50

@Foxboron Hm. If the signal handler is installed first of all, then all AddKeys work. Is possession of keyring tied to a specific process state, which is altered when changing signal handling?

=> More informations about this toot | More toots from quitelost@mastodon.social

Written by Morten Linderud on 2025-01-08 at 08:20

@quitelost

I'm a bit conflicted about what the culprint is. The signal handler causes a goroutine to spawn and that might change something around the osthread state?

I didn't consider the problem being the signal handler itself.

Hmmm

=> More informations about this toot | More toots from Foxboron@chaos.social

Written by daniel lublin on 2025-01-08 at 08:26

@Foxboron Doing a simple go func() { time.Sleep … }() before an AddKey does not cause the issue, so it's not a goroutine in its most simple case

=> More informations about this toot | More toots from quitelost@mastodon.social

Written by Morten Linderud on 2025-01-08 at 09:17

@quitelost

Okay. After a quick detour into the Go IRC channel the solution seems to create a single goroutine to deal with keyctl and run LockOSThread on it.

Calling LockOSThread top-level in main solves the issue.

=> More informations about this toot | More toots from Foxboron@chaos.social

Written by daniel lublin on 2025-01-08 at 10:02

@Foxboron ah, so just setting up a signal handler might be affecting which goroutine is running on the main/first OS thread then (rather than keyring possession being tied to some process state involving signal mask)

=> More informations about this toot | More toots from quitelost@mastodon.social

Written by Morten Linderud on 2025-01-08 at 10:37

@quitelost

Some tip/pid thing gets changed around with the signal handler code it seems. But it seems to be workable.

Just gotta write a key peddler. However it's a bit annoying I need to pass around secrets between channels and threads when you want minimal exposure to limit the secret from staying in the memory.

=> More informations about this toot | More toots from Foxboron@chaos.social

Written by Morten Linderud on 2025-01-08 at 08:21

@quitelost

Cc @paul

If you happen to know why the kernel keyring fail in the above example code :)

As you wrote go-keyring at some point in time.

=> More informations about this toot | More toots from Foxboron@chaos.social

Written by Paul ‮etnomailgaT on 2025-01-08 at 15:58

@Foxboron @quitelost I've def been able to use goroutines and keyrings.

Check this out; I think it's signal handling (which is incredibly ... invasive ... in go)

https://gist.github.com/paultag/41ce383d6592146d1e912aaef3a4c811

=> More informations about this toot | More toots from paul@soylent.green

Written by Paul ‮etnomailgaT on 2025-01-08 at 15:59

@Foxboron

(output:)

created keyring

883195902 1

addkey this works 883195902 1

addkey this works again 883195902 1

addkey this works does not work 883195902 1

(success)

=> More informations about this toot | More toots from paul@soylent.green

Written by Paul ‮etnomailgaT on 2025-01-08 at 15:59

@Foxboron Also, unrelated, but you're welcome to take over pault.ag/go/keyring; I can move you the repo / add you to it, always down to collab with you again obviously

=> More informations about this toot | More toots from paul@soylent.green

Written by Morten Linderud on 2025-01-08 at 16:22

@paul

I'll POC things up in my ssh-tpm-agent code for some quick iterations for a v1.0 release there I think, i have a FOSDEM presentation deadline :p

But longterm i suspect this can be added to go-keyring and I wouldn't mind helping to maintain it.

=> More informations about this toot | More toots from Foxboron@chaos.social

Written by Paul ‮etnomailgaT on 2025-01-08 at 16:02

@Foxboron I'm unfortunately a bit short on time this week but my next steps are some strace between the binaries with signal handler and without, and work backwards to figure out what's different with the syscalls

=> More informations about this toot | More toots from paul@soylent.green

Written by Morten Linderud on 2025-01-08 at 16:19

@paul

We sorta figured it out. The signal handling does a switcheroo on the pid/tid of the process so we loose possession of the session keyring.

The solution is to run all keyctl syscalls in a separate goroutine with LockOSThread.

I suspect this is a nice addition to your go-keyring :)

=> More informations about this toot | More toots from Foxboron@chaos.social