Date: Sun, 24 Apr 2005 11:59:38 -0400 From: Yarema <yds@CoolRat.org> To: Jose M Rodriguez <josemi@freebsd.jazztel.es>, Oliver Lehmann <lehmann@ans-netz.de>, freebsd-ports@freebsd.org Cc: ports@dino.sk Subject: Re: splitting courier-authlib into master+slave ports Message-ID: <0561D730E8127604A75416F9@tuber.coolrat.org> In-Reply-To: <200504241605.32882.josemi@redesjm.local> References: <20050414111426.775f6afd.lehmann@ans-netz.de> <200504241413.23396.josemi@redesjm.local> <20050424151838.0046502c.lehmann@ans-netz.de> <200504241605.32882.josemi@redesjm.local>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Sunday, April 24, 2005 16:05:32 +0200 Jose M Rodriguez=20 <josemi@freebsd.jazztel.es> wrote: > El Domingo, 24 de Abril de 2005 15:18, Oliver Lehmann escribi=F3: >> Jose M Rodriguez wrote: >> > Also, I think an UPDATING entry must be done pointing that ports >> > that depends on this, must need BUILD_DEPENDS on >> > courier-authlib-base and RUN_DEPENDS on courier-authlib-pam to be >> > able of reading system passwd. >> >> I still don't see the point why we must force pam or pwd.db support >> to install? Why not left the choise to the user what "plugin" to >> install? A user who uses MySQL don't need PAM or pwd.db support same >> for me, I use vpopmail's user db. > > Well, I try this slowly > > three system auth modules come with courier-authlib > > libauthpwd -> for systems with old system 7 passwd, with real readable > passwords in /etc/passwd (very old systems, not FreeBSD) > > libauthshadow -> for systems with system V shadow passwords, but without > a pam lib (ej: Slackware linux). > > libauthpam -> for systems with a pam library (FreeBSD). > > And just one of this must be implemented. I think we only need > libauthpam, allthough libauthpwd may build and install (but it isn't > able to authtenticate). > > without this, you can't authenticate or locate system accounts. this is > a fact. > > Now, take out your 'courier-authlib point of view' and take this from a > 'courier-imap point of view' > > If you RUN_DEPENDS on courier-authlib-base instead of > courier-authlib-pam, you will end with a default courier-imap install > that isn't able to read system accounts. I don't think this is > acceptable. > > This is why I point to make courier-authlib-base with authpam, in the > sense you can get from the actual pkg-descr. > > This is not any set of auth modules, just the one base module needed to > read system accounts. And if you fill this dangerous or not needed, > you can easy tweak authdaemonrc to not load the authpam module. > > I think that it easy expect a pro user implementing a virtual mail > system have the resources to edit authdaemonrc that a home user trying > to install courier-imap can locale the real need of installing > courier-authlib-pam to get his system accounts working. Thank you, josemi. That's pretty much been my stance on this from day=20 one. You spelled it out quite clearly. Oliver, your description of how libauthpwd works is incorrect. You=20 describe it as offering "/etc/pwd.db support" which implies that it works=20 directly with that file. However the description in=20 <http://www.Courier-MTA.org/authlib/README_authlib.html>; reads as follows: The authpwd authentication module This modules obtains account information and passwords from the /etc/passwd = file. NOTE: This module doesn't actually read the /etc/passwd file, it uses the C = library's getpw() functions. The C library implementation could use any=20 mechanism to obtain the equivalent information. Which means that if one has NIS set up the account info would be gotten=20 from there. etc. and if you lookup the man page for getpw(3) two things=20 jump out: 1) the library this function lives in is libcompat 2) the getpw() function is made obsolete by getpwuid(3) Further down in the authpam section of=20 <http://www.Courier-MTA.org/authlib/README_authlib.html>; we get the=20 following: The authpam authentication module This modules uses the system's PAM library (pluggable authentication=20 modules) for authentication. This is, essentially, a way to use existing=20 PAM modules for authentication. Note, however, that the authenticated=20 account's home directory, userid and groupid are still read from the=20 /etc/passwd file, since PAM functionality is limited to validating account=20 passwords. NOTE: The specific configuration steps differ from system to system.=20 Consult the system documentation for more information. It might be tempting = to throw in a towel and use authshadow or authpwd if you cannot figure out=20 how to *install* PAM support, however that is not advisable. It is highly=20 recommended to use authpam wherever the PAM library is available. I added the emphasis on *install*. Well, we *can* figure out how to=20 install authpam and there is no OS_VERSION of FreeBSD supported by the=20 ports system which does not contain PAM in the base OS. Which makes=20 authpwd completely undesirable anywhere near a FreeBSD system. As for having authpam in the base courier-authlib port. The library is=20 only 6476 bytes on my build. There's more space wasted leaving the lib*.a=20 files in the base install. So space is not an argument. The argument=20 seems to be that you only use vchkpw some other user only uses=20 userdb,ldap,mysql,pgsql and authpam is not needed for you. That's what=20 authmodulelist is for in authdaemonrc -- to specifically list only the=20 modules you want considered for user authentication. Having authpam=20 installed as part of the base courier-authlib won't hurt you. But having a = courier-authlib which is not capable of doing anything out-of-the-box might = be painfull for someone looking at courier for the first time. Having to=20 find out what's causing the pain from an UPDATING file might cause further=20 frustration. The already provided documentation is painful enough. Also take a look at courier-authlib.spec to see how the packaging is=20 organized on an rpm system. There's no separate authpam or authpwd=20 package. Authentication to system accounts is included in the "base"=20 install. The subpackages are split because they require extra library=20 dependencies one might not want when all they need is a working=20 courier-authlib. Not because they qualify as auth modules. That's one of=20 the reasons you had to write extra patches to prevent authpwd form being=20 installed. courier-authlib was never intended by its author to be=20 installed without a system authmodule. courier-authlib.spec and you=20 needing to patch it to accomplish that is evidence enough. To sum it up not including authpam is more difficult to maintain and the=20 benefit is rather negligible: having a pure courier-authlib which only=20 contains the one authmodule you selected. The benefit of including authpam = in the base is no patching to remove authpwd from the base install,=20 --with-authpam does that for you and fewer authmodules for a user to=20 consider: base courier-authlib for system account authentication -- any of=20 the plugins to use anything above and beyond system accounts. For some=20 authpam would be sufficient even if they wanna use LDAP since it's possible = to configure PAM that way. --=20 Yarema http://yds.CoolRat.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0561D730E8127604A75416F9>