david l goodrich <d...@dsrw.org> writes: > It's a custom kernel, because it's a Xen domU. Which probably invites > all kinds of pain. But its config file is used in a different Xen domU, > which works fine. I've attached it, I'm not very adept at reading these > files. It works for me, so I just copy it to my new systems and build > the kernel with whatever version of gcc the new machine requires.
Indeed, the kernel isn't built with keyring support: > # > # Security options > # > # CONFIG_KEYS is not set CONFIG_KEYS is the relevant setting. Now, that doesn't explain why it's working elsewhere, particularly if the same versions of everything are involved. In some ways, it raises more questions than it answers, such as how you're getting PAGs at all since the other way of doing them isn't exported in current kernels (but it may be that this is an older version). However, I suspect that if you enable CONFIG_KEYS and build an AFS kernel module against the resulting kernel, you'll find that this starts working. If I had to guess, I'd say that the AFS module is managing to create the group for the PAG but failing to hook into setgroups, so then when ssh calls setgroups, it blows away the PAG again and you lose access to your token. No idea why that isn't happening on your other systems too. It's likely that OpenAFS will completely drop support for kernels without keyring support in some future version, since doing anything else is just too ugly and is explicitly not supported by the Linux kernel developers. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
