On Mon, 2026-04-27 at 18:12 +0000, Marek Greško wrote: > Great analysis. I found out there are some ways of configuring gssd in > /etc/nfs.conf. Mys current config for it states: > > use-gss-proxy=1 > > There are available options > > # cred-cache-directory= > # use-memcache=0 > > Would not one of these options solve my problem?
memcache may be worth a try, the only issue is that a process restart means loosing the cache and having to go back to the KDC to acquire a new TGT, but that shouldn't be a big deal. > I think the memory cache woudl be better. Are there any culprits I am not > aware of not to do it like this? The memory cache is a cache collection and could lead to some interesting issues, but it may be worth a try. > If the second option with cred directory is used, what is the recommended > diretory in Fedora to use? Should I use /var/lib/nfs? Any directory that is accessible by rpc.gssd and is not world writable will not cause selinux issues will be fine, given your users never litter /tmp with ccaches. In fact an otherwise empty directory will speed up some operations when rpc.gssd decided to "scan" the ccache directory for user caches. > Thanks > > Marek > > > Odoslané pomocou bezpečného emailu Proton Mail. > > pondelok 27. apríla 2026, 19:33, Simo Sorce via Kerberos <[email protected]> > napísal/a: > > > Gssproxy never stores caches in /tmp, that file is more likely created > > by rpc.gssd the NFS Client daemon that handles GSSAPI authentication. > > > > rpc.gssd is sadly stuck in time and forces the use of the FILE: ccache > > through most of its code, which is why we intercept it with gssproxy > > for some operations with user ccaches only. > > > > HTH, > > Simo. > > > > On Mon, 2026-04-27 at 17:02 +0000, Marek Greško via Kerberos wrote: > > > Hello, > > > > > > so for klist it seems it is generated by gssproxy, because there is nfs/ > > > ticket. > > > > > > Regarding gssproxy.conf I have the file > > > /etc/gssproxy/99-network-fs-clients.conf containing: > > > > > > [service/network-fs-clients] > > > mechs = krb5 > > > cred_store = keytab:/etc/krb5.keytab > > > cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U > > > cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab > > > cred_usage = initiate > > > allow_any_uid = yes > > > trusted = yes > > > euid = 0 > > > min_lifetime = 60 > > > > > > But apparently it is not using the path. I also did not find how to > > > specify path for machine ccache. Even better, if I could convince machine > > > ccache to be also stored in KCM. Is it possible? > > > > > > Thanks > > > > > > Marek > > > > > > > > > > > > > > > Odoslané pomocou bezpečného emailu Proton Mail. > > > > > > pondelok 27. apríla 2026, 16:19, Christian, Mark > > > <[email protected]> napísal/a: > > > > > > > On Mon, 2026-04-27 at 04:38 +0000, Marek Greško wrote: > > > > > Hello, > > > > > > > > > > the > > > > > kinit -c /tmp/krb5ccmachine_EXAMPLE.COM > > > > > asks for password. Which password? What should I expect thereafter to > > > > > happen? > > > > > > > > Sorry I meant for you to use klist, not kinit: > > > > > > > > % klist -c /tmp/krb5ccmachine_EXAMPLE.COM > > > > > > > > > > > > > > I also asked AI to help me on the original issue. It thinks it is > > > > > related to gssproxy and most probably it is right. It stated there is > > > > > not nuch to do and I should accept the current state. But I feel a > > > > > little bit unhappy, since it creates file with predictable name in > > > > > the /tmp and it could be a security risk. > > > > > > > > see man gssproxy.conf for details on howto configure the location of > > > > cred_store / ccache. > > > > > > > > Mark > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Marek > > > > > > > > > > > > > > > > > > > > Odoslané pomocou bezpečného emailu Proton Mail. > > > > > > > > > > piatok 24. apríla 2026, 16:02, Christian, Mark > > > > > <[email protected]> napísal/a: > > > > > > > > > > > On Fri, 2026-04-24 at 10:44 +0000, Marek Greško via Kerberos wrote: > > > > > > > Hello, > > > > > > > > > > > > > > I have configured kerberos client on Fedora 43. I configured > > > > > > > kerberos > > > > > > > to use KCM: ccache. Users ccaches are in KCM, but I always see > > > > > > > the > > > > > > > file /tmp/krb5ccmachine_EXAMPLE.COM created. Why is this file > > > > > > > created? > > > > > > > > > > > > Perhaps related to your kerberos NFS configuration? Inspect the > > > > > > cache, > > > > > > kinit -c /tmp/krb5ccmachine_EXAMPLE.COM, doing so might clue you > > > > > > in. > > > > > > > > > > > > Mark > > > > > > > > > > > > > What mechanism does not use KCM and how could it be convinced to > > > > > > > do > > > > > > > so? > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Marek > > > > > > > ________________________________________________ > > > > > > > Kerberos mailing list [email protected] > > > > > > > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > > > > > > > > > ________________________________________________ > > > > > > Kerberos mailing list [email protected] > > > > > > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > > > > > > > > > > > ________________________________________________ > > > > Kerberos mailing list [email protected] > > > > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > > > > > > > ________________________________________________ > > > Kerberos mailing list [email protected] > > > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > -- > > Simo Sorce > > Distinguished Engineer > > RHEL Crypto Team > > Red Hat, Inc > > > > > > ________________________________________________ > > Kerberos mailing list [email protected] > > https://mailman.mit.edu/mailman/listinfo/kerberos > > -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
