pam_fscrypt doesn't update login passphrase when protector file is not writeable by user

[JackCasual]

Using fscrypt 0.3.0-1 on Linux 5.14.8-arch1-1
PAM chains configured following the wiki plus option debug
Created the user and homedir using root inside install chroot.

login[397]: LOGIN ON tty1 BY user
kernel: fscrypt: AES-256-XTS using implementation "xts-aes-aesni"
passwd[523]: pam_unix(passwd:chauthtok): password changed for user
pam_fscrypt[523]: Chauthtok(map[debug:true]) starting
pam_fscrypt[523]: Current privs (real, effective): uid=(1000,0) gid=(1000,1000) groups=[998 1000]
pam_fscrypt[523]: Setting euid=1000 egid=1000 groups=[1000 998]
pam_fscrypt[523]: Current privs (real, effective): uid=(1000,1000) gid=(1000,1000) groups=[998 1000]
pam_fscrypt[523]: Reading config from "/etc/fscrypt.conf"
pam_fscrypt[523]: creating context for user "user"
pam_fscrypt[523]: found ext4 filesystem "/" (/dev/sda2)
pam_fscrypt[523]: listing descriptors in "/.fscrypt/protectors"
pam_fscrypt[523]: found 1 descriptor(s)
pam_fscrypt[523]: successfully read metadata from "/.fscrypt/protectors/f2a74811e4ef3c92"
pam_fscrypt[523]: Getting protector f2a74811e4ef3c92 from option
pam_fscrypt[523]: rewrapping login protector
pam_fscrypt[523]: running passphrase hash for protector f2a74811e4ef3c92
pam_fscrypt[523]: valid wrapping key for protector f2a74811e4ef3c92
pam_fscrypt[523]: running passphrase hash for protector f2a74811e4ef3c92
pam_fscrypt[523]: writing metadata to "/.fscrypt/protectors/f2a74811e4ef3c92"
pam_fscrypt[523]: Setting euid=0 egid=1000 groups=[998 1000]
pam_fscrypt[523]: Current privs (real, effective): uid=(1000,0) gid=(1000,1000) groups=[998 1000]
pam_fscrypt[523]: Chauthtok(map[debug:true]) failed: rename /.fscrypt/protectors/.tmp239625066 /.fscrypt/protectors/f2a74811e4ef3c92: operation not permitted

Resolved by owning the protector file:
chown user:root /.fscrypt/protectors/f2a74811e4ef3c92

I didn't use fscrypt before but maybe this worked prior changes in privilege handling by always executing as root?

Thanks for your work :)

[Eric Biggers]

I think the correct fix for this is to make login protectors by owned by the correct user if they are created by root. #331 does this.