On Tue, Jun 20, 2017 at 04:23:30PM -0400, Daniel Walsh wrote: > On 06/20/2017 02:45 PM, Jakub Hrozek wrote: > > On Tue, Jun 20, 2017 at 08:55:49AM -0400, Daniel Walsh wrote: > > > 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? > > Bind-mount the KCM server socket into the 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? > > Well, UID of the peer accessing the socket is the access control key right > > now. Unlike Heimdal's KCM, root doesn't have any special powers (with > > Heimdal's KCM, root can list any ccache, with our implementation, only > > that of UID 0). > > > > Do you have a different suggestion? > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > I would want an SELinux check added to it, to allow us to keep the caches > separate, based on SELinux. This would mean you would need to have an > SELinux label associated with each cache. > > I would also be careful about capabilities. > > The bottom line with this is if I have two different containers creating > keyrings, how does you cache differentiate the the keyrings from each other. > If I am in container1 and I do a kinit, and it container2, I can use the > keyring, that is a HUGE security violation. Well, isn't the kernel KEYRING: cache (which we default to..) working exactly this way at the moment? With the KCM deamon, you at least selectively mount the KCM socket into the containers where you /want/ to share the ccache based on the peer UID. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
