From nobody Tue Aug 08 09:53:28 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RKpRN1sFhz4m5XD for ; Tue, 8 Aug 2023 09:53:36 +0000 (UTC) (envelope-from SRS0=KM5H=DZ=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RKpRM68rpz4Rfb for ; Tue, 8 Aug 2023 09:53:35 +0000 (UTC) (envelope-from SRS0=KM5H=DZ=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Received: from rwvirtual372.colo.realworks.nl (rwvirtual372.colo.realworks.nl [10.0.10.72]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4RKpRD4TS7z3wdX; Tue, 8 Aug 2023 11:53:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1691488408; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LnNejo7UPa4wHZeiTZwU7hMWxnAggHzSK0xt9nDOB64=; b=q/exhqrlP4noEDpg7Zzpkk9Ha/RlMwI9e+PjPMGV6FFtw0BDzPUJh6sadSCkVBavesHFos WN4rA+TjI01R/j9qxN5w7LulcEkzDHhKnsStvKAFYVDsjdvPf08Yany66FOHqcQ/S4TCtd 1yiIUm4GfCofGpzrP3dvO31AFXm3EUUoku3X47VdBiFa1gWerkXsMhT67l+lzVr7iyQXyl 1wQ+tjBKxoyQ/X9NKfhHVmrvXzc9R2GdYbv17oMXyySqrYX/MEyO49LSWlQy4NgT5EJRBR XhRCoZHYP2L+ffWwt5LnHlf3/LTUquavUXf4dFaAm1g3IB2n/L06muSBhpCOhQ== Received: from rwvirtual372.colo.realworks.nl (localhost [127.0.0.1]) by rwvirtual372.colo.realworks.nl (Postfix) with ESMTP id 7167F1C06A8; Tue, 8 Aug 2023 11:53:28 +0200 (CEST) Date: Tue, 8 Aug 2023 11:53:28 +0200 (CEST) From: Ronald Klop To: Michael Grimm Cc: freebsd-current@freebsd.org Message-ID: <1361461519.2835.1691488408412@localhost> In-Reply-To: <613E7476-6553-4A74-BF33-EF95D95F25A9@ellael.org> References: <613E7476-6553-4A74-BF33-EF95D95F25A9@ellael.org> Subject: Re: 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so? List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2834_799853935.1691488408382" X-Mailer: Realworks (665.159) X-Originating-Host: from (84-105-120-103.cable.dynamic.v4.ziggo.nl [84.105.120.103]) by rwvirtual372 [10.0.10.72] with HTTP; Tue, 08 Aug 2023 11:53:28 +0200 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/116.0 X-Rspamd-Queue-Id: 4RKpRM68rpz4Rfb X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL] ------=_Part_2834_799853935.1691488408382 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Michael Grimm Datum: maandag, 7 augustus 2023 22:43 Aan: freebsd-current@freebsd.org Onderwerp: 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so? > > Hi, > > I'm currently in the process to prepare for upcoming 14-STABLE. Thus, I upgraded one of my sytems from 13-STABLE to 14-CURRENT. > > Everything went fine, except for programs that need /usr/lib/pam_opie.so which are: > > 1) jexec /usr/bin/login -u > 2) redis-server > 3) mariadb1011-server > > Error messages: > > su[6371]: in openpam_load_module(): no pam_opie.so found > su[6371]: pam_start: System error > > Well, although it has been reported some time ago that pam_opie and pam_opieaccess.so will become removed in Freebsd 14, there is a port security/opie providing both libraries. Quick workaround. > > But I want to understand why the above mentioned programs do fail although not dynamically linked against /usr/lib/pam_opie.so > > MWN> ldd /usr/bin/login > /usr/bin/login: > libutil.so.9 => /lib/libutil.so.9 (0xd408ecf7000) > libpam.so.6 => /usr/lib/libpam.so.6 (0xd408f6f2000) > libbsm.so.3 => /usr/lib/libbsm.so.3 (0xd4090dab000) > libc.so.7 => /lib/libc.so.7 (0xd408f99d000) > [vdso] (0xd408e18f630) > > MWN> ldd /usr/local/bin/redis-server > /usr/local/bin/redis-server: > libthr.so.3 => /lib/libthr.so.3 (0x89a8847f000) > libm.so.5 => /lib/libm.so.5 (0x89a87beb000) > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x89a891c7000) > libssl.so.30 => /usr/lib/libssl.so.30 (0x89a8a271000) > libcrypto.so.30 => /lib/libcrypto.so.30 (0x89a8b02b000) > libc.so.7 => /lib/libc.so.7 (0x89a8c7fe000) > libelf.so.2 => /lib/libelf.so.2 (0x89a8949b000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x89a8bb85000) > [vdso] (0x89a87323630) > > MWN> ldd /usr/local/libexec/mariadbd > /usr/local/libexec/mariadbd: > libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x145ae576f000) > libwrap.so.6 => /usr/lib/libwrap.so.6 (0x145ae64a5000) > libcrypt.so.5 => /lib/libcrypt.so.5 (0x145ae74be000) > libz.so.6 => /lib/libz.so.6 (0x145ae7d0b000) > libm.so.5 => /lib/libm.so.5 (0x145ae8b3e000) > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x145ae6e03000) > libssl.so.30 => /usr/lib/libssl.so.30 (0x145ae9575000) > libcrypto.so.30 => /lib/libcrypto.so.30 (0x145aeafff000) > libc++.so.1 => /lib/libc++.so.1 (0x145ae9e3b000) > libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x145aeaa85000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x145aec745000) > libthr.so.3 => /lib/libthr.so.3 (0x145aebf10000) > libc.so.7 => /lib/libc.so.7 (0x145aec7fa000) > libelf.so.2 => /lib/libelf.so.2 (0x145aee867000) > [vdso] (0x145ae5010630) > > Which alternatives to pam_opie should I investigate? > Reason: I want to get rid of security/opie > > Thanks and regards, > Michael > > > > > Hi, Might it be possible that pam_opie is still mentioned in a file in /etc/pam.d/* on your machine? An alternative might be https://www.freshports.org/security/pam_google_authenticator See also: https://lists.freebsd.org/archives/freebsd-security/2022-September/000081.html Regards, Ronald. ------=_Part_2834_799853935.1691488408382 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Michael Grimm <trashcan@ellael.org>
Datum: maandag, 7 augustus 2023 22:43
Aan: freebsd-current@freebsd.org
Onderwerp: 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so?

Hi,

I'm currently in the process to prepare for upcoming 14-STABLE. Thus, I upgraded one of my sytems from 13-STABLE to 14-CURRENT.

Everything went fine, except for programs that need /usr/lib/pam_opie.so which are:

1) jexec <jailname> /usr/bin/login -u <user>
2) redis-server
3) mariadb1011-server

Error messages:

    su[6371]: in openpam_load_module(): no pam_opie.so found
    su[6371]: pam_start: System error

Well, although it has been reported some time ago that pam_opie and pam_opieaccess.so will become removed in Freebsd 14, there is a port security/opie providing both libraries. Quick workaround.

But I want to understand why the above mentioned programs do fail although not dynamically linked against /usr/lib/pam_opie.so

MWN> ldd /usr/bin/login
    /usr/bin/login:
    libutil.so.9 => /lib/libutil.so.9 (0xd408ecf7000)
    libpam.so.6 => /usr/lib/libpam.so.6 (0xd408f6f2000)
    libbsm.so.3 => /usr/lib/libbsm.so.3 (0xd4090dab000)
    libc.so.7 => /lib/libc.so.7 (0xd408f99d000)
    [vdso] (0xd408e18f630)

MWN> ldd /usr/local/bin/redis-server
    /usr/local/bin/redis-server:
    libthr.so.3 => /lib/libthr.so.3 (0x89a8847f000)
    libm.so.5 => /lib/libm.so.5 (0x89a87beb000)
    libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x89a891c7000)
    libssl.so.30 => /usr/lib/libssl.so.30 (0x89a8a271000)
    libcrypto.so.30 => /lib/libcrypto.so.30 (0x89a8b02b000)
    libc.so.7 => /lib/libc.so.7 (0x89a8c7fe000)
    libelf.so.2 => /lib/libelf.so.2 (0x89a8949b000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x89a8bb85000)
    [vdso] (0x89a87323630)

MWN> ldd /usr/local/libexec/mariadbd
    /usr/local/libexec/mariadbd:
    libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x145ae576f000)
    libwrap.so.6 => /usr/lib/libwrap.so.6 (0x145ae64a5000)
    libcrypt.so.5 => /lib/libcrypt.so.5 (0x145ae74be000)
    libz.so.6 => /lib/libz.so.6 (0x145ae7d0b000)
    libm.so.5 => /lib/libm.so.5 (0x145ae8b3e000)
    libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x145ae6e03000)
    libssl.so.30 => /usr/lib/libssl.so.30 (0x145ae9575000)
    libcrypto.so.30 => /lib/libcrypto.so.30 (0x145aeafff000)
    libc++.so.1 => /lib/libc++.so.1 (0x145ae9e3b000)
    libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x145aeaa85000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x145aec745000)
    libthr.so.3 => /lib/libthr.so.3 (0x145aebf10000)
    libc.so.7 => /lib/libc.so.7 (0x145aec7fa000)
    libelf.so.2 => /lib/libelf.so.2 (0x145aee867000)
    [vdso] (0x145ae5010630)

Which alternatives to pam_opie should I investigate?
Reason: I want to get rid of security/opie

Thanks and regards,
Michael

 


Hi,

Might it be possible that pam_opie is still mentioned in a file in /etc/pam.d/* on your machine?
An alternative might be https://www.freshports.org/security/pam_google_authenticator

See also: https://lists.freebsd.org/archives/freebsd-security/2022-September/000081.html

Regards,
Ronald.
  ------=_Part_2834_799853935.1691488408382--