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

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

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

Toot

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

Descendants