On Thu, Nov 3, 2011 at 4:46 PM, Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: > On Thu, 2011-11-03 at 17:30 -0400, Simo Sorce wrote: >> I have discussed use of the keyring in a private discussion before >> starting the thread, and it turns out the keyring has a number of >> limitations that makes it probably unsuitable for this project. >> >> As an upcall mechanism it has some limitations on the size of the >> payloads, IIRC limited to a page, and that means that you cannot pass >> blobs carrying big kerberos tickets. I never meant storing the ccache, or even the TGTs in the keyring. >> As a storage mechanism for credential caches it also has size limits. >> Currently the limit is 20k per user which is not even enough to hold a >> single ticket in some cases. This limit can be increased of course, but >> then you end keeping around a huge amount of unswappable ram depending >> on the number of users. > > Allowing keys to be swapped out is a really really really really really > really bad idea when your kernel depends upon them being available as > part of the memory reclaim process, as would be the case when you are > talking about NFS, CIFS or AFS dirty page writebacks. If you have local swap you'll be fine. Of course, the text for the gssd had better be in-core. Diskless over NFS doesn't work all that well, IMO. Obviously you'll need to be able to block the triggering process/syscall, and you'll need to make sure there's no deadlock, but the first is a given (since we're talking about NFS) and the second should be possible if gssd does not stray into any NFS mounts (see my comment about disklessness over NFS). But even if you want diskless over NFS with RPCSEC_GSS (you'll want RPCSEC_GSSv3) you can make this work by ensuring that all of the text of gssd and its libraries and plugins and... are pinned in-core, and by not swapping over NFS. The way Linux boot works this is quite feasible. You'll want ccaches stored in tmpfs, of course. >> So for long term storage of credentials we will probably not rely on >> kernel keyrings, nor as an upcall mechanism. > > So this would be an argument for scrapping keyrings from the kernel? If > they're not good for kerberos tickets, why would we want to keep them at > all? > What would you replace them with, given the above requirements > concerning swapping? No, I don't think it's an argument for scrapping keyrings, just for not storing actual credentials in them (store references to them instead). I like to think that my CPG proposal for Solaris from a few years ago is much cleaner than keyrings. But keyrings could be made to do. Nico -- -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
