ccache using linux keyring
dhowells at redhat.com
Sat Apr 16 07:03:37 EDT 2005
Ken Raeburn <raeburn at MIT.EDU> wrote:
> > The PAGE_SIZE limit on the keyring contents would limit a ccache to
> > approximately 1000 tickets. Does that sound like it will be a problem?
> Is that ~1000 total entries in the key ring, counting each Kerberos ticket and
> the principal name for each ccache, and each AFS token (one per cell, though I
> vaguely recall hearing someone suggest per-server authentication, which would
> greatly increase this number), and whatever else is stored there?
The content of a keyring is maximum PAGE_SIZE; given you lose a bit for a
header, this gives it the ability to point to up to ~1000 other keys or
keyrings on a 32-bit system with 4KB pages. On a 64-bit system, this will of
course be more like 500 keys.
However, this hard limit is _not_ recursive, so theoretically you could have,
for example, a keyring that holds a thousand pointers to other keyrings, each
of which point to a thousand keys.
So you might want to arrange things thus:
+---> Kerberos Keyring
+---> Realm redhat.com keyring
| +---> NFS4 key
| +---> AFS key
| +---> Login key
+---> Realm myhomedomain.org.uk keyring
+---> NFS4 key
+---> AFS key
+---> Login key
Note, however, that each keyring consumes a certain amount of the user's
quota and a certain amount of kernel memory resources, which is why there _is_
> That could add up to quite a lot for some people, I would guess. But if it
> filled, some sort of LRU scheme could evict some entries which are useless or
> would be easily re-acquired (say, any Kerberos tickets but your initial one,
> or any that are about to expire in five seconds anyways, or an older one for
> the same service and same flags but an earlier expiration) when more space is
> needed. Wouldn't be ideal, but it might work.
Keys can be set to expire.
> For most people, I think ~1000 tickets is way more than enough....
I hope so...
More information about the krbdev