Description of problem: No O_TRUNC causes the xauthority file corruption. In case the address of XDMCP DISPLAY length differs. 1st access came from "192.168.1.1:1". 2nd access came from "hostname.com:2". And close 1st access. The result of # xauth -f /var/run/lightdm/lightdm/xauthority list is as follows. hostname/unix0 MIT-MAGIC-COOKIE-1 xxxxxxxx. hostname.com:2 MIT-MAGIC-COOKIE-1 yyyyyyyy. And next access from "192.168.1.2:2" hostname/unix0 MIT-MAGIC-COOKIE-1 xxxxxxx...x. hostname.com:2 MIT-MAGIC-COOKIE-1 yyyyy...yyy. 192.168.1.2:2 MIT-MAGIC-COOKIE-1 zzzzzzz...zz. And close the session from "hostname.com:2" will cause the corruption. hostname/unix0 MIT-MAGIC-COOKIE-1 xxxxxxx...x. 192.168.1.2:2 MIT-MAGIC-COOKIE-1 zzzzzzz...zz. #$weq321% 3 44ddaawe3we12312421412z. This is because, without O_TRUNC will open original file itself, REMOVE will delete the entry of hostname.com:2 , but the length is too big to 192.168.1.2:2. Version-Release number of selected component (if applicable): How reproducible: No O_TRUNC causes the xauthority file corruption. In case the address of XDMCP DISPLAY length differs. Steps to Reproduce: 1.Access from IPv4 address. 2.Access from FQDN resolvable hostname. 3.Then xauthority will corruopt. How to fix this problem: src/xauthority.c now: int output_fd = g_open (filename, O_WRONLY | O_CREAT, S_IRUSR | S_IWUSR); FIXED: int output_fd = g_open (filename, O_WRONLY | O_CREAT | O_TRUNC , S_IRUSR | S_IWUSR); -- This pull request has already merged cannonical/lightdm. https://github.com/canonical/lightdm/pull/202
FEDORA-2022-088850eb6f has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-088850eb6f
FEDORA-2022-088850eb6f has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.