Looking into responder_common.c, the function client_recv logs "Invalid data from client, closing connection" if sss_packet_recv returned EINVAL.
Looking into sss_packet_recv, EINVAL is returned if the packet is too large. Decoding the packet, the first four bytes are the packet length which is 1905; the second four are the command type which is 0xfb or SSS_GSSAPI_SEC_CTX. After the eight status/reserved bytes are the first 1520 bytes of the packet body. The rest of the packet body is never read because after the first recvfrom call (into a buffer of 1536 bytes), the connection is closed. I can see the definition of SSS_PACKET_MAX_RECV_SIZE is 1024. And I can see some code in sss_packet_recv that handles two types of packet known to be larger (SSS_NSS_GETNAMEBYCERT and SSS_NSS_GETLISTBYCERT, which are allowed to be up to SSS_CERT_PACKET_MAX_RECV_SIZE bytes or 10240 bytes long). So maybe the SSS_GSSAPI_SEC_CTX command needs similar handling of longer packets so that it can deal with large kerberos tickets (which Windows users will have if they are in lots of groups; a quick Google suggests the PAC may grow up to 48 KiB as of Windows Server 2012). -- Sam Morris <https://robots.org.uk/> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9 _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
