You can subscribe to this list here.
2001 |
Jan
(24) |
Feb
(632) |
Mar
(97) |
Apr
(98) |
May
(47) |
Jun
(27) |
Jul
(44) |
Aug
(49) |
Sep
(34) |
Oct
(49) |
Nov
(10) |
Dec
(60) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(40) |
Feb
(68) |
Mar
(12) |
Apr
(20) |
May
(91) |
Jun
(110) |
Jul
(62) |
Aug
(43) |
Sep
(46) |
Oct
(79) |
Nov
(39) |
Dec
(64) |
2003 |
Jan
(50) |
Feb
(26) |
Mar
(62) |
Apr
(32) |
May
(54) |
Jun
(34) |
Jul
(29) |
Aug
(39) |
Sep
(58) |
Oct
(104) |
Nov
(19) |
Dec
(18) |
2004 |
Jan
(36) |
Feb
(24) |
Mar
(17) |
Apr
(47) |
May
(50) |
Jun
(45) |
Jul
(38) |
Aug
(54) |
Sep
(40) |
Oct
(18) |
Nov
(24) |
Dec
(24) |
2005 |
Jan
(33) |
Feb
(31) |
Mar
(38) |
Apr
(27) |
May
(17) |
Jun
(16) |
Jul
(23) |
Aug
(19) |
Sep
(14) |
Oct
(43) |
Nov
(2) |
Dec
(6) |
2006 |
Jan
(4) |
Feb
(14) |
Mar
(17) |
Apr
(5) |
May
(10) |
Jun
(9) |
Jul
|
Aug
(7) |
Sep
(10) |
Oct
(2) |
Nov
(18) |
Dec
(7) |
2007 |
Jan
(29) |
Feb
(8) |
Mar
(8) |
Apr
(6) |
May
(8) |
Jun
(4) |
Jul
(13) |
Aug
(10) |
Sep
(11) |
Oct
(19) |
Nov
(6) |
Dec
(1) |
2008 |
Jan
(4) |
Feb
(9) |
Mar
(9) |
Apr
(13) |
May
|
Jun
(2) |
Jul
(12) |
Aug
(5) |
Sep
(6) |
Oct
(15) |
Nov
(1) |
Dec
(1) |
2009 |
Jan
(3) |
Feb
(27) |
Mar
(5) |
Apr
(1) |
May
(55) |
Jun
(23) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(9) |
Dec
(2) |
2010 |
Jan
(3) |
Feb
(13) |
Mar
(2) |
Apr
(2) |
May
(25) |
Jun
(4) |
Jul
(5) |
Aug
|
Sep
(5) |
Oct
(2) |
Nov
|
Dec
(20) |
2011 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(5) |
May
(7) |
Jun
(4) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
(3) |
Nov
(10) |
Dec
(12) |
2012 |
Jan
(4) |
Feb
|
Mar
(9) |
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
|
Mar
(10) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
(8) |
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(2) |
Dec
(3) |
2014 |
Jan
(3) |
Feb
|
Mar
|
Apr
(1) |
May
(7) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
2015 |
Jan
|
Feb
(2) |
Mar
|
Apr
(3) |
May
(7) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
(7) |
Nov
(2) |
Dec
|
2016 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
|
Nov
(8) |
Dec
|
2017 |
Jan
(4) |
Feb
(9) |
Mar
(11) |
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(3) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(6) |
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
(9) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(6) |
Jul
|
Aug
|
Sep
(4) |
Oct
(2) |
Nov
|
Dec
(2) |
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: Jesse S S. <js...@in...> - 2001-02-02 01:51:17
|
On Thu, Feb 01, 2001 at 11:02:00PM +0000, TJ Saunders wrote: > > jss>I'll put the new patch into bug 435 and commit to cvs. > > Which new patch, yours or mine? ;) I ended up going with yours, which I saw right after I uploaded mine to bugzilla. Yours had nifty reporting. ;) -- "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 -- 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 01:47:58
|
Hmmm...for some reason, this didn't seem to go through the first time... ---------------------------------------------------------------- TJ Saunders <tj...@di...> ---------------------------------------------------------------- ---------- Forwarded message ---------- Date: Thu, 1 Feb 2001 22:00:17 +0000 (GMT) From: TJ Saunders <tj...@di...> To: pro...@pr... Subject: Bug#407 I know it's not on the Bug#427 list, but did you want to commit the patch to this Include bug, Jesse? ---------------------------------------------------------------- TJ Saunders <tj...@di...> ---------------------------------------------------------------- |
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: 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-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: <bu...@pr...> - 2001-02-02 00:08:46
|
http://bugs.proftpd.net/show_bug.cgi?id=435 *** shadow/435 Thu Feb 1 17:57:08 2001 --- shadow/435.tmp.6700 Thu Feb 1 18:01:35 2001 *************** *** 147,149 **** --- 147,152 ---- ------- Additional Comments From js...@in... 2001-02-01 17:57 ------- Commited TJ's second patch timestamp 02/01/01 17:26 NOT the one stamped 02/01/01 17:47 + + ------- Additional Comments From tj...@di... 2001-02-01 18:01 ------- + Hehe...that's funny. =) \ No newline at end of file -- 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: <bu...@pr...> - 2001-02-01 23:09:47
|
http://bugs.proftpd.net/show_bug.cgi?id=435 *** shadow/435 Thu Feb 1 17:47:17 2001 --- shadow/435.tmp.6658 Thu Feb 1 17:57:08 2001 *************** *** 2,9 **** | Chrooted user remains at root privelages. | +----------------------------------------------------------------------------+ | Bug #: 435 Product: ProFTPD | ! | Status: ASSIGNED Version: 1.2.0rc2 | ! | Resolution: Platform: PC | | Severity: critical OS/Version: Linux | | Priority: P1 Component: core | +----------------------------------------------------------------------------+ --- 2,9 ---- | Chrooted user remains at root privelages. | +----------------------------------------------------------------------------+ | Bug #: 435 Product: ProFTPD | ! | Status: RESOLVED Version: 1.2.0rc2 | ! | Resolution: FIXED Platform: PC | | Severity: critical OS/Version: Linux | | Priority: P1 Component: core | +----------------------------------------------------------------------------+ *************** *** 142,144 **** --- 142,149 ---- ------- Additional Comments From js...@in... 2001-02-01 17:47 ------- Created an attachment (id=133) Update to TJ's patch, checks for null return variable + + + ------- Additional Comments From js...@in... 2001-02-01 17:57 ------- + Commited TJ's second patch timestamp 02/01/01 17:26 NOT the one stamped + 02/01/01 17:47 \ No newline at end of file -- 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: <bu...@pr...> - 2001-02-01 23:08:31
|
http://bugs.proftpd.net/show_bug.cgi?id=435 *** shadow/435 Thu Feb 1 17:28:22 2001 --- shadow/435.tmp.6626 Thu Feb 1 17:47:17 2001 *************** *** 138,140 **** --- 138,144 ---- Found my earlier problem -- was not properly checking for a NULL return value. Patch now catches -1 UID/GIDs as needed, and handles unknown ID and names properly. + + ------- Additional Comments From js...@in... 2001-02-01 17:47 ------- + Created an attachment (id=133) + Update to TJ's patch, checks for null return variable -- 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: <bu...@pr...> - 2001-02-01 23:08:30
|
http://bugs.proftpd.net/show_bug.cgi?id=435 *** shadow/435 Thu Feb 1 17:26:54 2001 --- shadow/435.tmp.6598 Thu Feb 1 17:28:22 2001 *************** *** 132,134 **** --- 132,140 ---- ------- Additional Comments From tj...@di... 2001-02-01 17:26 ------- Created an attachment (id=132) Better fix for checking -1 UID/GID in auth_* functions + + + ------- Additional Comments From tj...@di... 2001-02-01 17:28 ------- + Found my earlier problem -- was not properly checking for a NULL return value. + Patch now catches -1 UID/GIDs as needed, and handles unknown ID and names + properly. \ No newline at end of file -- 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: <bu...@pr...> - 2001-02-01 23:08:29
|
http://bugs.proftpd.net/show_bug.cgi?id=435 *** shadow/435 Thu Feb 1 16:57:07 2001 --- shadow/435.tmp.6583 Thu Feb 1 17:26:54 2001 *************** *** 128,130 **** --- 128,134 ---- Hmmm...this patch needs to be expanded a bit, I think. In testing the opposite case, where the UID/GID that appears is 65535, I hit upon a bug in build_group_arrays() that causes a segfault. + + ------- Additional Comments From tj...@di... 2001-02-01 17:26 ------- + Created an attachment (id=132) + Better fix for checking -1 UID/GID in auth_* functions -- 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-01 23:08:06
|
jss>I'll put the new patch into bug 435 and commit to cvs. Which new patch, yours or mine? ;) ---------------------------------------------------------------- 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-01 23:06:18
|
On Thu, Feb 01, 2001 at 05:46:41PM -0500, Jesse S Sipprell wrote: > On Thu, Feb 01, 2001 at 09:25:54PM +0000, TJ Saunders wrote: > > > > jss>I shouldn't worry about it too much in mod_tar. I mean, that DOES probably > > jss>need to go into the attic anyway. ;) > > > > OK. Am verifying my patch for this right now. Works for -1, but having > > 65535 in the UID/GID fields is causing a SEGV. Need to track that down, > > first. =P > > Ahhh, ok, I see the problem. Your patch assumes that the return variable in > the various functions always contains a valid pointer, which is not true if > the handler was unable to fetch the requested data (example: calling > auth_getgrgid() with a gid that doesn't have an actual entry in /etc/group). > I fixed, tested with 65535 and all seems well. > > I'll put the new patch into bug 435 and commit to cvs. Nevermind, I see you already got it. ;) -- "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 -- 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: cvs <cv...@ev...> - 2001-02-01 22:58:06
|
cvs 2001/02/01 17:58:08 EST Modified files: include version.h Log: Bug #435 - uid/gid checking for -1, updated version string to 1.2.0rc3 Revision Changes Path 1.11 +1 -1 proftpd-1.2/include/version.h |
From: cvs <cv...@ev...> - 2001-02-01 22:58:06
|
cvs 2001/02/01 17:58:08 EST Modified files: src auth.c Log: Bug #435 - uid/gid checking for -1, updated version string to 1.2.0rc3 Revision Changes Path 1.6 +84 -1 proftpd-1.2/src/auth.c |
From: Jesse S S. <js...@in...> - 2001-02-01 22:53:23
|
On Thu, Feb 01, 2001 at 09:25:54PM +0000, TJ Saunders wrote: > > jss>I shouldn't worry about it too much in mod_tar. I mean, that DOES probably > jss>need to go into the attic anyway. ;) > > OK. Am verifying my patch for this right now. Works for -1, but having > 65535 in the UID/GID fields is causing a SEGV. Need to track that down, > first. =P Ahhh, ok, I see the problem. Your patch assumes that the return variable in the various functions always contains a valid pointer, which is not true if the handler was unable to fetch the requested data (example: calling auth_getgrgid() with a gid that doesn't have an actual entry in /etc/group). I fixed, tested with 65535 and all seems well. I'll put the new patch into bug 435 and commit to cvs. -- "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 -- 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: <se...@ci...> - 2001-02-01 22:43:40
|
+------ Jesse S Sipprell wrote (Thu, 1-Feb-01, 16:00 -0500): | | I shouldn't worry about it too much in mod_tar. I mean, that DOES probably | need to go into the attic anyway. ;) Non-causal agreement! 8-) See my comments for BugID#188. http://bugs.proftpd.net/show_bug.cgi?id=188 I would also like to see a couple of README files moved around, but that is a topic for another thread. Cheers, Chuck -- Charles Seeger <se...@ci...> -- 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: <bu...@pr...> - 2001-02-01 22:09:26
|
http://bugs.proftpd.net/show_bug.cgi?id=435 *** shadow/435 Thu Feb 1 16:15:30 2001 --- shadow/435.tmp.6508 Thu Feb 1 16:57:07 2001 *************** *** 84,86 **** --- 84,130 ---- ------- Additional Comments From tj...@di... 2001-02-01 16:15 ------- Created an attachment (id=131) Adds UID/GID checks to auth_* functions + + + ------- Additional Comments From tj...@di... 2001-02-01 16:57 ------- + Have tested the submitted patch by attempting to log in with a user that had, in + one try, a UID of -1, and in the other try, a GID of -1. Results: + + UID of -1 + + localhost.localdomain (localhost.localdomain[127.0.0.1]) - received: USER guest + localhost.localdomain (localhost.localdomain[127.0.0.1]) - error: UID of -1 not + allowed + localhost.localdomain (localhost.localdomain[127.0.0.1]) - error: UID of -1 not + allowed + localhost.localdomain (localhost.localdomain[127.0.0.1]) - received: PASS + (hidden) + localhost.localdomain (localhost.localdomain[127.0.0.1]) - error: UID of -1 not + allowed + localhost.localdomain (localhost.localdomain[127.0.0.1]) - error: UID of -1 not + allowed + localhost.localdomain (localhost.localdomain[127.0.0.1]) - error: UID of -1 not + allowed + localhost.localdomain (localhost.localdomain[127.0.0.1]) - USER guest (Login + failed): Can't find user. + GID of -1 + + localhost.localdomain (localhost.localdomain[127.0.0.1]) - received: USER guest + localhost.localdomain (localhost.localdomain[127.0.0.1]) - error: GID of -1 not + allowed + localhost.localdomain (localhost.localdomain[127.0.0.1]) - error: GID of -1 not + allowed + localhost.localdomain (localhost.localdomain[127.0.0.1]) - received: PASS + (hidden) + localhost.localdomain (localhost.localdomain[127.0.0.1]) - error: GID of -1 not + allowed + localhost.localdomain (localhost.localdomain[127.0.0.1]) - error: GID of -1 not + allowed + localhost.localdomain (localhost.localdomain[127.0.0.1]) - error: GID of -1 not + allowed + localhost.localdomain (localhost.localdomain[127.0.0.1]) - USER guest (Login + failed): Can't find user. + + Hmmm...this patch needs to be expanded a bit, I think. In testing the opposite + case, where the UID/GID that appears is 65535, I hit upon a bug in + build_group_arrays() that causes a segfault. \ No newline at end of file -- 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: <bu...@pr...> - 2001-02-01 22:09:20
|
http://bugs.proftpd.net/show_bug.cgi?id=435 *** shadow/435 Sun Jan 28 19:40:45 2001 --- shadow/435.tmp.6456 Thu Feb 1 16:15:30 2001 *************** *** 80,82 **** --- 80,86 ---- ------- Additional Comments From js...@in... 2001-01-28 19:40 ------- Updated into #427, the release-critical list. + + ------- Additional Comments From tj...@di... 2001-02-01 16:15 ------- + Created an attachment (id=131) + Adds UID/GID checks to auth_* functions -- 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-01 22:00:26
|
I know it's not on the Bug#427 list, but did you want to commit the patch to this Include bug, Jesse? ---------------------------------------------------------------- TJ Saunders <tj...@di...> ---------------------------------------------------------------- |
From: TJ S. <tj...@di...> - 2001-02-01 21:32:20
|
jss>I shouldn't worry about it too much in mod_tar. I mean, that DOES probably jss>need to go into the attic anyway. ;) OK. Am verifying my patch for this right now. Works for -1, but having 65535 in the UID/GID fields is causing a SEGV. Need to track that down, first. =P ---------------------------------------------------------------- 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: <bu...@pr...> - 2001-02-01 21:09:12
|
http://bugs.proftpd.net/show_bug.cgi?id=451 *** shadow/451 Thu Feb 1 14:51:06 2001 --- shadow/451.tmp.6334 Thu Feb 1 15:25:06 2001 *************** *** 117,119 **** --- 117,127 ---- ------- Additional Comments From js...@in... 2001-02-01 14:51 ------- Committed to CVS. + + ------- Additional Comments From bol...@dc... 2001-02-01 15:25 ------- + verified: + rsbac:/home/boldi/src/proftpd-1.2# /usr/local/sbin/proftpd + rsbac.ebizlab.hit.bme.hu - unable to set uid to 65534, current uid: 0 + + thanks, + boldi \ No newline at end of file -- 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-01 21:06:56
|
On Thu, Feb 01, 2001 at 08:36:34PM +0000, TJ Saunders wrote: > > I've got the -1 UID/GID bug almost all patched up -- excerpt for one small > case. At present, mod_tar.c is the only place which calls the > auth_name_uid() and auth_name_gid() functions, which return uid_t and > gid_t, respectively. > > >From around line 267 in mod_tar.c: > > /* fixup uid and gid if possible */ > uid = auth_name_uid(p,t->t_uname); > gid = auth_name_gid(p,t->t_gname); > > if(uid != -1) > t->t_uname = pstrdup(p,auth_uid_name(p,uid)); > if(gid != -1) > t->t_gname = pstrdup(p,auth_gid_name(p,gid)); > > Is that if check sufficient, or does there need to be an else? Any ideas? I shouldn't worry about it too much in mod_tar. I mean, that DOES probably need to go into the attic anyway. ;) -- "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 -- 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-01 20:36:56
|
I've got the -1 UID/GID bug almost all patched up -- excerpt for one small case. At present, mod_tar.c is the only place which calls the auth_name_uid() and auth_name_gid() functions, which return uid_t and gid_t, respectively. From=20around line 267 in mod_tar.c: /* fixup uid and gid if possible */ uid =3D auth_name_uid(p,t->t_uname); gid =3D auth_name_gid(p,t->t_gname); if(uid !=3D -1) t->t_uname =3D pstrdup(p,auth_uid_name(p,uid)); if(gid !=3D -1) t->t_gname =3D pstrdup(p,auth_gid_name(p,gid)); Is that if check sufficient, or does there need to be an else? Any ideas? ---------------------------------------------------------------- TJ Saunders=09=09=09<tj...@di...> ---------------------------------------------------------------- |
From: Jesse S S. <js...@in...> - 2001-02-01 20:19:41
|
On Thu, Feb 01, 2001 at 07:55:40PM +0000, TJ Saunders wrote: > > jss>Actually, I think this is a different, but related problem, > jss>PRIVS_SETUP is never checked to make sure all went well. In his > jss>case he is using RSBAC, with rules defined which prohibit proftpd > jss>from switching uids. I've got a patch here that should do the > jss>trick, I'll send it his way. > > Ahh...cool. Could you post the patch somewhere, too, so we could take a > look? =) It's attached to bug #451 on bugs.proftpd.net. I went ahead and committed after doing some minimal testing, as it is exceedingly trivial. -- "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 -- 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. |