From: TJ S. <tj...@di...> - 2001-02-02 01:10:46
|
dave>I am curious to know whether ProFTPd uses the OS's C library to dave>perform user/pass lookups or whether it reads /etc/passwd or dave>shadow directly with fgetpwXXX ? Ummm...yes and no. =) It depends on the module being used. If you're using AuthUserFile, or /etc/passwd, then mod_unixpw is responsible for doing the lookups -- I believe it uses fgetpwent() and friends. mod_sqlpw in conjunction with mod_pgsql or mod_mysql, and mod_ldap, do not rely on that. The modules provide a custom getpwnam() function. dave>While browsing the source I cannot follow the auth sequence dave>completely to determine whether or not the standard getpwnam and dave>friends are being called or not. The key will be the auth_getpwnam() et al functions. These functions are actually dispatcher functions, and will call the function listed in a module's authtab. mod_unixpw and mod_ldap provide examples of using the authtab to override the system/library authentication functions. dave>I make use of a custom NSS library which is called from glibc dave>but if an application reads directly from the /etc/passwd then dave>it obviously would not be used. If you're using an NSS module, then mod_unixpw and the fgetpwent() calls should work you. If they don't...be sure to let us know. =) Hope that helps... ---------------------------------------------------------------- TJ Saunders <tj...@di...> ---------------------------------------------------------------- -- To unsubscribe, send mail to pro...@pr... with "unsubscribe" in the subject field of the message. http://www.proftpd.net -- The Official ProFTPD web site. http://bugs.proftpd.net -- Bug reporting and feature requests. |
From: Dave <da...@cc...> - 2001-02-01 19:59:11
|
I am curious to know whether ProFTPd uses the OS's C library to perform user/pass lookups or whether it reads /etc/passwd or shadow directly with fgetpwXXX ? While browsing the source I cannot follow the auth sequence completely to determine whether or not the standard getpwnam and friends are being called or not. I make use of a custom NSS library which is called from glibc but if an application reads directly from the /etc/passwd then it obviously would not be used. Thanks for any information -Dave |
From: Dave <da...@cc...> - 2001-02-02 00:42:16
|
I am curious to know whether ProFTPd uses the OS's C library to perform user/pass lookups or whether it reads /etc/passwd or shadow directly with fgetpwXXX ? While browsing the source I cannot follow the auth sequence completely to determine whether or not the standard getpwnam and friends are being called or not. I make use of a custom NSS library which is called from glibc but if an application reads directly from the /etc/passwd then it obviously would not be used. Thanks for any information -Dave -- To unsubscribe, send mail to pro...@pr... with "unsubscribe" in the subject field of the message. http://www.proftpd.net -- The Official ProFTPD web site. http://bugs.proftpd.net -- Bug reporting and feature requests. |
From: Dave <da...@cc...> - 2001-02-02 01:43:14
|
Thanks TJ! > doing the lookups -- I believe it uses fgetpwent() and friends. mod_sqlpw > in conjunction with mod_pgsql or mod_mysql, and mod_ldap, do not rely on > that. The modules provide a custom getpwnam() function. Understood > dave>While browsing the source I cannot follow the auth sequence > dave>completely to determine whether or not the standard getpwnam and > dave>friends are being called or not. > > The key will be the auth_getpwnam() et al functions. These functions are > actually dispatcher functions, and will call the function listed in a > module's authtab. mod_unixpw and mod_ldap provide examples of using the > authtab to override the system/library authentication functions. Yes, that is what I suspected....I traversed it a little and noticed the variable function being called somewhere deep in there (is that the correct terminology?? variable function...I am not a C programmer..;) ). > dave>I make use of a custom NSS library which is called from glibc > dave>but if an application reads directly from the /etc/passwd then > dave>it obviously would not be used. > > If you're using an NSS module, then mod_unixpw and the fgetpwent() calls > should work you. If they don't...be sure to let us know. =) Thats what got me stumped a little...I don't know that fgetpwent() uses NSS at all, does it? And if it doesn't and if ProFTPd is emulating a getpwnam -> fgetpwent internally then NSS is completely bypassed I would think. I was under the impression from reading fgetpwent(3) that it is bypassing NSS altogether....hmm...looks like it is. Do you have any tips to configure ProFTPd to use conventional getpwnam/getgrpnam/etc calls from the OS's libc and to not use the internal getpwnam "emulation" ?? My reason for needing to use conventional getpw calls is because of some legacy(??) applications which I would prefer to operate unmodified (patched/hacked with PAM/other) and use my own NSS lib which does everything transparently to the application. Thanks for your assistance... -Dave > Hope that helps... > > ---------------------------------------------------------------- > TJ Saunders <tj...@di...> > ---------------------------------------------------------------- > > -- To unsubscribe, send mail to pro...@pr... with "unsubscribe" in the subject field of the message. http://www.proftpd.net -- The Official ProFTPD web site. http://bugs.proftpd.net -- Bug reporting and feature requests. |
From: Jesse S S. <js...@in...> - 2001-02-02 02:12:05
|
> > dave>While browsing the source I cannot follow the auth sequence > > dave>completely to determine whether or not the standard getpwnam and > > dave>friends are being called or not. > > > > The key will be the auth_getpwnam() et al functions. These functions are > > actually dispatcher functions, and will call the function listed in a > > module's authtab. mod_unixpw and mod_ldap provide examples of using the > > authtab to override the system/library authentication functions. > > Yes, that is what I suspected....I traversed it a little and noticed the > variable function being called somewhere deep in there (is that the correct > terminology?? variable function...I am not a C programmer..;) ). The terminology you are probably looking for is "function pointer," although I can't be sure without knowing exactly what bit of code you are referring to .;) > > > dave>I make use of a custom NSS library which is called from glibc > > dave>but if an application reads directly from the /etc/passwd then > > dave>it obviously would not be used. > > > > If you're using an NSS module, then mod_unixpw and the fgetpwent() calls > > should work you. If they don't...be sure to let us know. =) > > Thats what got me stumped a little...I don't know that fgetpwent() uses NSS > at all, does it? And if it doesn't and if ProFTPd is emulating a getpwnam -> > fgetpwent internally then NSS is completely bypassed I would think. > > I was under the impression from reading fgetpwent(3) that it is bypassing > NSS altogether....hmm...looks like it is. > > Do you have any tips to configure ProFTPd to use conventional > getpwnam/getgrpnam/etc calls from the OS's libc and to not use the internal > getpwnam "emulation" ?? That's a complex issue. ;) The problem is anonymous FTP (or any chroot'd environment, actually). When inside chroot, one can't just pop /etc/passwd open any old time. Proftpd gets around this with a feature called PersistentPasswd, which causes mod_unixpw to use fgetpwent() in combination with a permanently-held-open file. If this featurs is off, mod_unixpw should use normal getgrnam() and friends. Whether the feature defaults to on or off depends on what the autoconf configure script detects for your system, linux boxen will almost certainly have it on by default, while freebsd may not. Regardless, you can turn it off via the PersistentPasswd directive. The side affects of doing so may be the inability to see user and group names inside chroot. This may not affect you, depending on what your NSS library does. Keep in mind that the NSS library will be subject to exactly the same chroot restrictions once proftpd decides it's going to chroot(). You'll also want to make sure no other proftpd authentication modules are getting in the way (mod_pam, mod_sqlpw, etc). > My reason for needing to use conventional getpw calls is because of some > legacy(??) applications which I would prefer to operate unmodified > (patched/hacked with PAM/other) and use my own NSS lib which does everything > transparently to the application. > > > > Thanks for your assistance... > > -Dave > > > Hope that helps... > > > > ---------------------------------------------------------------- > > TJ Saunders <tj...@di...> > > ---------------------------------------------------------------- > > > > > > -- > To unsubscribe, send mail to pro...@pr... with > "unsubscribe" in the subject field of the message. > > http://www.proftpd.net -- The Official ProFTPD web site. > http://bugs.proftpd.net -- Bug reporting and feature requests. -- "In the event of a failure, the system can be configured to automatically restart itself. This feature of Windows NT Server provides maximum system up-time." -- Reliability and Fault Tolerance in Windows NT Server, MSC |
From: TJ S. <tj...@di...> - 2001-02-02 02:27:33
|
jss>open any old time. Proftpd gets around this with a feature called jss>PersistentPasswd, which causes mod_unixpw to use fgetpwent() in jss>combination Ahh...that's right. I forgot about that whole PersistentPasswd bit...=) ---------------------------------------------------------------- TJ Saunders <tj...@di...> ---------------------------------------------------------------- -- To unsubscribe, send mail to pro...@pr... with "unsubscribe" in the subject field of the message. http://www.proftpd.net -- The Official ProFTPD web site. http://bugs.proftpd.net -- Bug reporting and feature requests. |
From: TJ S. <tj...@di...> - 2001-02-02 02:15:00
|
dave>> If you're using an NSS module, then mod_unixpw and the fgetpwent() calls dave>> should work you. If they don't...be sure to let us know. =) dave> dave>Thats what got me stumped a little...I don't know that dave>fgetpwent() uses NSS at all, does it? And if it doesn't and if dave>ProFTPd is emulating a getpwnam -> fgetpwent internally then NSS dave>is completely bypassed I would think. ProFTPD doesn't reimplement getpwnam or fgetpwnam internally...but I think it does provide a getpwnam() face that calls fgetpwnam() -- it's just a matter of which file fgetpwnam() is given. dave>Do you have any tips to configure ProFTPd to use conventional dave>getpwnam/getgrpnam/etc calls from the OS's libc and to not use dave>the internal getpwnam "emulation" ?? Sure...you could provide your own getpwnam wrapper functions, which call the library routines, in a module authtab. One note of caution, though -- if you do do this, I recommend providing functions for _every_ authtab hook (described in the doc/API document). Due to module loading order, this would mean your module's custom auth functions, no matter which, would be called first. If you don't provide your function for each hook, then you might have your custom auth functions called for that one hook, and a different auth function for a different hook -- 'tis best to be consistent about the auth functions entirely. =) dave>Thanks for your assistance... Anytime! =) ---------------------------------------------------------------- TJ Saunders <tj...@di...> ---------------------------------------------------------------- -- To unsubscribe, send mail to pro...@pr... with "unsubscribe" in the subject field of the message. http://www.proftpd.net -- The Official ProFTPD web site. http://bugs.proftpd.net -- Bug reporting and feature requests. |