-
gitomat[illumos-gate] 18349 pchsmbus panics on unexpected I/O error -- Robert Mustacchi <rm⊙fo>
-
gitomat[illumos-gate] 18235 nvme: don't panic on I/O to a removed shared namespace -- Alexey Romanov <romanov.alexey2000⊙gc>
-
gitomat[illumos-gate] 18408 core(5) should describe the old NOTE segment as historical -- Andy Fiddaman <illumos⊙fn>
-
gitomat[illumos-gate] 18398 SCTP sockets reject all IPPROTO_IP options following 18351 -- Andy Fiddaman <illumos⊙fn>
-
gemelena generic illumos and solaris question: for an encrypted zfs homedir, were there any solutions to bridge pam_zfs_key usage in case of passwordless remote user login (say ssh pubkey or others)?
-
jbki'm not aware of any offhand...
-
jbkthe problem is mounting an encrypted zfs dataset requires a key, so where does it go and how do you get it to zfs?
-
jbkIIUC, pam_zfs_key prompts the user
-
jbkbut if you're not going to do that, then how do you get it in a manner that's still secure?
-
jbkyou could maybe escrow the zfs key somewhere wrapped by your ssh public key, but then where do you keep that?
-
jbk(triton does something kinda like this, but it assumes that is the only way the dataset is being unlocked
-
jbk(it also doesn't use pam)
-
sommerfeldperhaps an ssh protocol or ssh-agent protocol extension to pass the keys around when you're connected. but there's also the question of crisply defining your threat model and ensuring the key management is consistent with it..