Permissions on system-wide initial challenge file prevent user-owned processes from authenticating

[dhgwilliam]

I followed the instructions here for system-wide challenge-response auth and PAM is working fine for logging in and sudo, but every time I use sudo, the file in /var/yubico/david-XXXXX has its permissions reset to root:david, 0600. This prevents user-owned processes like i3lock and gnome-screensaver from reading the initial challenge and consequently means I'm locked out of my Xwindows session until I change the permissions on that file manually so that my user can read it.

[klali]

this was changed around in 1036873 which with your comments obviously isn't the complete solution. Maybe we should try to not change the file permissions when writing out the state.

[crosser]

In my challenge-response PAM module I copy the ownership of the old copy of the file to the newly created copy. I call fstat() on the old copy, and after I create the new copy by before I rename it, I call fchown() on it. I think this is a reasonable approach for PAM related files, that can be used both by root and by the user.

[klali]

Yes, something like 155b485 just pushed to a new branch..

@dhgwilliam it'd be great if you where willing to test that branch and see if it fixes your issues

[dhgwilliam]

Based on some very quick testing, this does fix my problem. I'll continue to use this branch today and let you know if anything changes.

[conz27]

@dhgwilliam: if the permissions are set to 0600 with ownership root:david, did you have to change the file permissions to 0640 on /var/run/yubico/david-XXXXX for the user-owned processes to access the file?

By default, ykpamcfg sets the file permissions to 0600, which would still require initial user intervention to correct.

[Joeviocoe]

Is there a workaround for this? Or am I expected to recompile with this commit 155b485?

Kubuntu has this issue when using the shared /var/yubico directory per the instructions. Linux Mint seems unaffected using the same configuration.

[patvdleer]

Can confirm, this only happens when the calresp_path is set to shared (/var/yubico in my case)

Package: libpam-yubico
Version: 2.24-1~ppa1~xenial1

[klali]

The fix in 155b485 is in 2.24.
@patvdleer what specific issues are you seeing? The same as the original reporter that the state file changes ownership or something different?

[patvdleer]

Issue #113 but on GNOME Shell 3.20.4

[klali]

So that's not this issue, that issue is about user-owned processes with the state file only being read/write for root whereas this issue was about a bug that was fixed.