ClearTxt UAM auth doesn't work with max len passwd on OpenBSD

[rdmark]

trafficstars

When attempting to authenticate with the passwd ClearTxt UAM on OpenBSD, the client will immediately throw an error.

The logs aren't helpful.

Mar 24 02:51:19.186903 afpd[958] {afp_dsi.c:617} (debug:AFPDaemon): <== Start AFP command: AFP_LOGIN
Mar 24 02:51:19.188001 afpd[958] {uams_passwd.c:61} (info:ad): cleartext login: dmark
Mar 24 02:51:19.264694 afpd[958] {dsi_cmdreply.c:24} (debug:DSI): dsi_cmdreply(DSI ID: 2, len: 0): START
Mar 24 02:51:19.264798 afpd[958] {dsi_cmdreply.c:33} (debug:DSI): dsi_cmdreply(DSI ID: 2, len: 0): END
Mar 24 02:51:19.264842 afpd[57217] {main.c:502} (debug:AFPDaemon): main: IPC request from child[958]
Mar 24 02:51:19.264921 afpd[958] {afp_dsi.c:109} (note:AFPDaemon): AFP statistics: 0.08 KB read, 0.06 KB written via DSI
Mar 24 02:51:19.264929 afpd[958] {dircache.c:619} (info:AFPDaemon): dircache statistics: entries: 0, lookups: 0, hits: 0, misses: 0, added: 0, removed: 0, expunged: 0, evicted: 0
Mar 24 02:51:19.265617 afpd[57217] {main.c:177} (info:AFPDaemon): child[958]: done

[rdmark]

Turns out this happens only when exactly len 8 passwords are used.

[rdmark]

The failure occurs when comparing the password string with the input buffer:

    p = crypt(password, pwd->pw_passwd);
    if (strcmp(p, pwd->pw_passwd) != 0)

...so I'm suspecting either garbage values or difference in null termination.

[rdmark]

~~It's universal: All BSDs, Linux. Both PAM and passwd auth.~~

[NJRoadfan]

This was working fine with Netatalk 4.1.1 with PAM on Debian Trixie. Will test with main later.

[rdmark]

Pardon, the universal bug seems to be with the afpfs-ng client (afpcmd).

Reverted the description of the bug back to impacting OpenBSD specifically. Neither NetBSD nor FreeBSD is impacted.

Note that this concerns non-PAM authentication specifically. There's a separate ticket for PAM on OpenBSD being completely broken.

[rdmark]

This no longer reproduces in the bleeding edge main code today, against the same OpenBSD VM. Not sure if a subsequent code change had an impact, or if there was something environmental at the time.

This is what the debug logs looks like for a successful case.

Jul 12 10:26:50.807645 afpd[68400] {afp_dsi.c:663} (debug:AFPDaemon): <== Start AFP command: AFP_LOGIN
Jul 12 10:26:50.819544 afpd[68400] {uams_passwd.c:62} (info:ad): cleartext login: dmark
Jul 12 10:26:50.836718 afpd[68400] {auth.c:282} (note:AFPDaemon): Login by dmark (AFP2.2)
Jul 12 10:26:50.839063 afpd[68400] {auth.c:289} (debug:AFPDaemon): obj->options.admingid == 0
Jul 12 10:26:50.841770 afpd[68400] {auth.c:330} (debug:AFPDaemon): login: supplementary groups:  1000 0
Jul 12 10:26:50.842580 afpd[68400] {server_ipc.c:326} (debug:AFPDaemon): ipc_child_write(IPC_LOGINDONE)
Jul 12 10:26:50.844032 afpd[74142] {main.c:550} (debug:AFPDaemon): main: IPC request from child[68400]
Jul 12 10:26:50.844682 afpd[74142] {server_ipc.c:232} (debug:AFPDaemon): ipc_server_read(IPC_LOGINDONE): pid: 68400
Jul 12 10:26:50.844917 afpd[74142] {server_ipc.c:115} (debug:AFPDaemon): ipc_login_done(pid: 68400, uid: 1000)
Jul 12 10:26:50.845143 afpd[74142] {server_child.c:367} (debug:Default): Setting client ID for 68400
Jul 12 10:26:50.847954 afpd[68400] {fce_api.c:629} (debug:Spotlight): register_fce(path: , event: FCE_LOGIN)
Jul 12 10:26:50.848464 afpd[68400] {afp_dsi.c:670} (debug:AFPDaemon): ==> Finished AFP command: AFP_LOGIN -> AFP_OK