[Bug 242132] Wrong GSS credentials cache expiration date for indefinite tickets

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242132

            Bug ID: 242132
           Summary: Wrong GSS credentials cache expiration date for
                    indefinite tickets
           Product: Base System
           Version: 12.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: pen at lysator.liu.se

Created attachment 209312
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=209312&action=edit
Patch to fix the cred_lifetime bug and add a kern.rpc.gss.lifetime_max sysctl

This is a bug that probably never happens in real life, or is masked by other
factors, but I think it's a bug anyway...

In
/usr/src/sys/rpc/rpcsec_gss/svc_rpcsec_gss.c:svc_rpc_gss_accept_sec_context()
there is a check:

             if (cred_lifetime == GSS_C_INDEFINITE)
                        cred_lifetime = time_uptime + 24*60*60;

                client->cl_expiration = time_uptime + cred_lifetime;

The assignment in the if-statement should be "cred_lifetime = 24*60*60;"
because the current code would set client->cl_expiration to
2*time_uptime+24*60*60 - if it ever was GSS_C_INDEFINITE. Atleast until year
2106 or so (when the unsigned 32bit cred_lifetime will wrap around)... 

Cache entries are invalidated when NFS shares are unmounted and most Kerberos
tickets do have a lifetime (10 hours typically) so this probably almost never
happens in real life but anyway...

I'd also like to propose adding a sysctl() where one can cap the cred_lifetime
to a lower value than the default (which is the ticket lifetime - about 10
hours on a "typical" system). With the current code a user being added to a new
group will not be "visible" for NFS until after the GSS cache entry expires (if
the user have something NFS-mounted from that server). It might be a good idea
to be able to force a lower timeout (like 1 hour or so).

-- 
You are receiving this mail because:
You are the assignee for the bug.