Closed jasperla closed 7 years ago
@stapelberg What do you think about this?
@jasperla Generally speaking we don't want compile-time flags in i3lock & family. It should just be platform-specific like the other things, though of course this leaves the pam dependency in OpenBSD. Besides, is there any reason why i3lock on OpenBSD should no longer support pam?
@Airblader it's not so much that i3lock on OpenBSD should no longer support PAM; rather that OpenBSD never had PAM. There is an openpam port but it's merely a stub library than anything else. I can see why you generally wouldn't want any compile time options, but for such fundamental things as the authentication backend that is system-specific (bsd_auth and more or less PAM too) I think it would be justified (I may be biased ;-)).
Thanks for the explanation – you can tell I'm not knowledgable on BSDs. :-) I'd rather leave this decision up to @stapelberg since it's pretty fundamental, as you pointed out yourself.
I don’t see why this needs to be optional. If OpenBSD doesn’t provide a working PAM stack, i3lock should always use bsd_auth(3)
on OpenBSD.
Can you update the PR to use ifdefs please?
The code is already using #ifdef
to conditionally compile either codepath.
Yes, but the ifdefs aren’t consistent with the way we’re using them in i3status/i3: you’re currently declaring a custom definition (USE_BSDAUTH
and USE_PAM
) whereas the rest of the code directly checks under which platform it is compiled.
Oh right, so #ifdef __OpenBSD__, #else, #endif
?
Yes.
That should do it.
Thanks!
Great, thanks a lot for the merge!
This PR adds support for
bsd_auth(3)
as an authentication backend to i3lock. To keep things simple it's a compile-time option and enabled by default on OpenBSD-only.In the process of keeping the actual addition of
bsd_auth(3)
as small as possible I renamed a lot of non-PAM specific variables/fields that hadPAM/pam
in them toAUTH/auth
. I think this will also make it easier for future backends to be added.