From owner-freebsd-current Sat Apr 28 4:54:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D93AC37B423 for ; Sat, 28 Apr 2001 04:54:36 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA24636; Sat, 28 Apr 2001 21:51:41 +1000 Date: Sat, 28 Apr 2001 21:50:33 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mark Murray Cc: current@FreeBSD.org Subject: Re: PAMmed su still broken for passwordless accounts In-Reply-To: <200104280901.f3S91Fp11808@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 28 Apr 2001, Mark Murray wrote: > > > 1) su on passwordless accounts. > > > (a) `su ' now bogusly prompts for a password. It lets > > > you in if you type an empty password. (a1) It also lets you in if you type garbage followed by a newline. > > > (b) `echo somecommand | su ' now bogusly prompts for > > > a password. su doesn't find a password, and exits without printing > > > anything or running `somecommand'. I use the latter form a lot. > > Feature, not bug. PAM has been told to use "unix" authentication. The bug turns out to be that PAM shouldn't have been told this. The non-PAM case uses the following check to avoid checking for passwords on passwordless accounts: --- /* if target requires a password, verify it */ if (*pwd->pw_passwd) { --- but the PAM case always calls pam_authenticate() (for non-root). > You can override this by setting > > su auth required pam_permit.so > > instead of > > su auth required pam_unix.so try_first_pass > > in /etc/pam.conf. > > For situations where some accounts have passwords and some don't, play > with the third word - "required" may become "sufficient" etc. The first form is equivalent to making all accounts passwordless. I don't see how changing the third word could affect this. login(1) uses the same configuration as su(1) in pam.conf but handles passwordless accounts correctly. In login.c, most of the complications for PAM authorization are in the auth_pam() function, and "goto ttycheck;" skips over all types of authorization when there is no password. The corresponding code in su.c is a tangle of ifdefs and large inline code for PAM authorization. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message