From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ectrolinux.com (S010602608cdb4440.vn.shawcable.net [24.85.200.54]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j5EBKhFL006904 for ; Tue, 14 Jun 2005 11:20:44 GMT Received: from entro.nv.ectrolinux.com (entro.nv.ectrolinux.com [172.16.1.3]) by mail.ectrolinux.com (Postfix) with ESMTP id 32341BC05D for ; Tue, 14 Jun 2005 11:20:43 +0000 (UTC) From: Anthony Gorecki To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] The results of an evening of Apache and PAM debugging Date: Tue, 14 Jun 2005 04:17:39 -0700 User-Agent: KMail/1.8.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5427436.TqXc2fWeF5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506140417.45475.agorecki@ectrolinux.com> X-Archives-Salt: c78d1edf-5a8b-4c72-be85-81eda1a0d1b1 X-Archives-Hash: 9dcef888d82828160d6576424c0b61c5 --nextPart5427436.TqXc2fWeF5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This message is fairly long, however I've decided to pass it along in the h= ope=20 that someone may find it useful as a reference source. It was originally=20 intended to be a problem description and debugging request for the gnomes t= o=20 ponder over. I've recently encountered an interesting debugging paradox. Upon deploying= =20 Subversion with an Apache-based server, I discovered an interesting issue=20 with PAM that seems to be intent on defying explanation: I have a repository that's accessible through , wi= th=20 the repository root set at location / (using Subversion 1.2.0, which has a= =20 fix for the cache bug that prevented repositories from being located at the= =20 root of a web address). The server is setup to allow read-only access to th= e=20 repository through unencrypted HTTP connections, while write operations mus= t=20 use HTTPS (TLSv1, AES256).=20 When accessing the repository through HTTPS, Apache dispatches an=20 authorization request to mod_auth_pam and PAM, which in turn passes the=20 request off as follows: The username and password authentication (auth) process is passed to pam_kr= b5=20 and the accompanying KDC. This process works flawlessly on every service,=20 including Apache's requests. The logs indicate successful logins when=20 submitting a username and password via web request. The account management (account) process is passed to pam_unix, which then= =20 does a bit of nsswitch magic to tie everything together. In this context,=20 only network-based user accounts are permitted, therefore nsswitch uses the= =20 NSVS (MySQL backend) service to retrieve all of the information. For exampl= e,=20 calls to getspnam are handled as follows: getspnam \ SELECT \ '%1$s','x',1,0,99999,7,0,DATEDIFF(expiration_date,'1970-01-01'),0 \ FROM users \ WHERE username=3D'%1$s' \ LIMIT 1 Herein lies the problem. During the authorization process, PAM will fail=20 during the account stage with the error: "PAM: user 'agorecki' - invalid=20 account: Authentication service cannot retrieve authentication info." =46or whatever reason, the debug and audit flags in the pam_unix module are= not=20 functional. As a result, I extracted the information I needed directly from= =20 the source code, and found the error location to be: =2E/Linux-PAM-0.78/modules/pam_unix/pam_unix_acct.c: 127 spent =3D _pammodutil_getspnam (pamh, uname); 128 else 129 return PAM_SUCCESS; 130 131 if (!spent) 132 if (on(UNIX_BROKEN_SHADOW,ctrl)) 133 return PAM_SUCCESS; 134 135 if (!spent) 136 return PAM_AUTHINFO_UNAVAIL; /* Couldn't get username from=20 shadow */ The call on line 127 takes place, and the error originates on line 136. =46or the purposes of debugging, I've removed all chroot restrictions from= =20 Apache and have given it complete access to the filesystem. The Apache=20 Subversion interface works through the unencrypted connections, which do no= t=20 require authentication. Hours of Google searching turned up nothing of use; what I don't understand= is=20 how Apache can fail to retrieve the shadow information when it's accessible= =20 by any unprivileged-- While writing the above, it occurred to me to run a final check on the debu= g=20 output of nsvsd, which produced:=20 run_query: query: SELECT 'agorecki','x',user_id,group_id,CONCAT(first_name,= '=20 ',last_name),CONCAT('/home/',username),'/bin/bash' FROM users WHERE=20 username=3D'agorecki' AND group_id IS NOT NULL LIMIT 1 send_response: sending 120-byte response main_loop: pid 12314 unauthorized for type 8 main_loop: pid 12314 unauthorized for type 8 The obligatory check of the code found: =2E/nsvs/src/nsvsd/nsvsd.c: 449 /* 450 * Don't allow shadow queries to non-root users 451 * It is CRITICAL that this code occurs AFTER reading the= =20 key 452 * to avoid clientside sigpipe issues 453 */ 454 if ((req.type =3D=3D GETSPBYNAME || req.type =3D=3D GETSP= ) &&=20 caller.uid !=3D 0) 455 { 456 nsvs_log (LOG_DEBUG, "%s: pid %d unauthorized for typ= e=20 %d", 457 __FUNCTION__, caller.pid, req.type); Having non-root users access the shadow-emulated MySQL information is of no= =20 consequence to me as I don't use that system for password storage, however= =20 I'd prefer not to start patching software to work around the above=20 restriction.=20 Having wasted forty-five minutes typing the above only to find the cause of= =20 the problem that was illuding me, I'm left with the next problem:=20 My network authentication scheme cannot solely rely on Kerberos' built-in=20 account expiration and suspension system, because a user could still login= =20 through SSH using a certificate. As a result, I've tied the entire system's= =20 account expiration process into the emulated shadow suite so that I can=20 expire all access simply by changing the expiration date of the account in= =20 the MySQL database. Consequently, I can't use the broken_shadow option of=20 pam_unix to get around the problem that way, otherwise I wouldn't be able t= o=20 keep someone from modifying the repository without deleting their account o= r=20 changing the account's password.=20 Therefore, the only viable option would seem to be to use mod_auth_external= =20 and an authentication binary to serve as an intermediary between PAM and=20 Apache. Unfortunately, that process would be considerably slower than calli= ng=20 the PAM functions directly or through a library. I also don't see a SASL=20 module for a Apache.=20 Does anyone have a suggestion that would fit the requirements, other than=20 using mod_auth_external, coupled with an authentication program? An interfa= ce=20 to Cyrus-SASL would be ideal since I already have saslauthd running for=20 Postfix.=20 In addition, does anyone have an idea as to what authentication program cou= ld=20 be used as the aforementioned intermediary? Thanks. =2D-=20 Anthony Gorecki Ectro-Linux Foundation --nextPart5427436.TqXc2fWeF5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.15 (GNU/Linux) iQIVAwUAQq682b8NHCarD3E0AQIEEBAAjFazyYTIQx0/2krRpxJXml++LZw4UjjE PYw5TCh1B1pIisrkXYpdPuqgV+XHKhk5yxyrnr6DnqEs47fYD6rKkrx9oEDFC1c6 eQNVam9Ykl3aaHRb+pZrLLbJk+YoDFo+Ah12ulys/xtSTOIsnw0h9vpH+S50y/fw cxB0Aq4OWgV1pphAMyJf6hZjb7skmiFLWxoCvy/zKXfppqVUR5AMjDN+7IXZu9c2 ftFSsWvtHfyKS+3lYG4Yv5dGoeDO+COe25wdujcNBz7D/iFnSp78rqe0qEmH428C AhB0DbW7PoqXqgrgAcDSCCyGgrCCDOYRrL3A4tNETO4tNbl6pWcNJvg6+r4/PPM8 7R1i6Kue9+CVA2nUq2PLgRKDXwLFyDoRwZK1xKIasgBwvAgiGonxgjO0qVQ9WBRz omro2uWevbWQcpTx8Ilbhc6ND8sqDA5fLCzDoiSFWRZVtELbyB+nmUmJLY26/GjT a3saGC6hRsQV2xwzghpI89Zb/zhHkEv5oaxiaieOObbyqx0qxcQxCFgNwVUrvGjQ Xy6CNkkIS+UnDhiqII3fg8gd8ZbFH2vAa9z/3P9T0z6vhuKLXGC7l4uJsHTcR9IP GCyLr13Kbf6NG2RVAY6U5OxKo5zvC5M7w1HRH/HuX9CKsbwY7eTuqVhhsFjVjnQP OIbg2kKl8dc= =QVMx -----END PGP SIGNATURE----- --nextPart5427436.TqXc2fWeF5-- -- gentoo-dev@gentoo.org mailing list