On 06/20/2017 04:21 AM, Jakub Hrozek wrote:
On Tue, Jun 20, 2017 at 09:25:49AM +0200, Pavel Cahyna wrote:
Hi,
On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote:
= System Wide Change: Kerberos KCM credential cache by default =
https://fedoraproject.org/wiki/Changes/KerberosKCMCache
"The design is described in more detail on the SSSD wiki."
It is not, the link redirects to a page about fedorahosted.org
retirement.
Sorry, your are right, I fixed the link (this feature was submitted
during f-26 timeframe when fh.o was still up and I forgot to change the
links when I re-submitted the feature..)
The correct link is:
https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html
Change owner(s):
* Jakub Hrozek <jhrozek AT redhat DOT com>
Default to a new Kerberos credential cache type called KCM which is
better suited for containerized environments and provides a better
user experience in the general case as well.
I wonder what is the relation to the daemon of the same name ansd
similar purpose distributed with Heimdal
http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html.
Will they be compatible?
Yes, more or less. The wire protocol is the same and I used MIT client
libraries with Heimdal server bit during development. Not all server
commands are implemented, only the subset that MIT client implements.
There are some features supported by Heimdal but not supported yet by SSSD's
KCM, like renewals, but those will be added. There are some features we
chose to explicitly not add (or not enable by default), like listing all
ccaches known to KCM server by root.
Hopefully the sssd upstream design page would help..
Will code be shared?
No, the Heimdal deamon relies on internal Heimdal API quite a bit. We
also want to support multiple 'storage back ends' for the ccaches, while
Heimdal only stores the ccaches in memory.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
How will I access this feature inside of a container? If there is a
leaked socket into the container, what kind of access control is built
into your server to prevent root inside of one container
effecting/accessing the credentials of different containers?
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
