FreeBSD support about xsecurelock HOT 6 CLOSED

xscreensaver solves the latter problem by being setuid root (same as chmod +s .../auth_pam_x11). Sure works, but absolutely not recommended, as a bug in auth_pam_x11 then could be used to take over the system.

from xsecurelock.

Build fix: 7f12231#diff-c2c3081275569a523f7b887c77722c5b

Warning fix: 7b8f363

What remains is unfortunately a larger thing - seems like the one way forward is to move the PAM conversation from auth_pam_x11 into a separate binary. That one then can be made setuid root.

from xsecurelock.

slock, xtrlock, metalock also all are setuid root on FreeBSD.

Still, not gonna do that for a screen locker that claims to be secure. auth_pam_x11 does quite a lot nowadays (even keyboard layout switching), could totally imagine that a bug inside libxkb would be exploitable.

Now the good news is, the separate PAM auth process might be a good idea on Linux too, so we could be sure to exercise this to be created interface everywhere. That way we're sure to notice possible bugs, and don't need two interfaces inside auth_pam_x11.

from xsecurelock.

Looks like on openbsd, setgid auth would be a somewhat better option; unfortunately /etc/spwd.db is root:wheel 600 on FreeBSD, so that's not an option here.

from xsecurelock.

Confirmed that the upcoming commit will fix the issue on FreeBSD (one will still have to manually chmod +s authproto_pam).

from xsecurelock.

Current version of the authproto branch now works also on OpenBSD, provided one installs the openpam port.

Installation notes have been updated in 2789d16 to cover FreeBSD and OpenBSD specifics.

from xsecurelock.