Re: wtmp locking problem (was: Re: SOLVED: Erk! Something is *really* wrong here!)
Now this IS the answer. I just downgraded one of my systems to sysvinit 2.69-1, rebooted, and the corruption seems to be gone. Few weeks ago, my corruption occured with sysvinit-2.69-1. I have been having this same package since December 8. For some unknown reason, few weeks ago my wtmp _stoped_ getting corrupted. And I have one dpkg request: An option that tells which packages were intalled since a certain date, i.g., % dpkg -older 2/28/97 . -- Ioannis Tambouras [EMAIL PROTECTED], West Palm Beach, Florida Signed pgp-key on key server.
Re: wtmp locking problem (was: Re: SOLVED: Erk! Something is *really* wrong here!)
On Thu, 6 Mar 1997, Joey Hess wrote: This doesn't explain why the problems have only started occurring in the past few days. I've been using the same set A/set B mix for many months, and only started getting corruption this week. Something must have changed, and that should be fixed. login changed. it was updated on approx Feb 20. craig
Re: wtmp locking problem (was: Re: SOLVED: Erk! Something is *really* wrong here!)
Craig Sanders: On Thu, 6 Mar 1997, Joey Hess wrote: This doesn't explain why the problems have only started occurring in the past few days. I've been using the same set A/set B mix for many months, and only started getting corruption this week. Something must have changed, and that should be fixed. login changed. it was updated on approx Feb 20. But I don't use the standard login, I use shadow-login. And I haven't changed it in a long time. -- #!/usr/bin/perl -pl- # ,,ep) ayf |)nj,, $_=reverse lc$_;s@@''@g;y/[]{A-U}()a-y1-9,!.?`'/][} # Joey Hess {)(eq)paj6y!fk7wuodbjsfn^mxhl5Eh29L86`i'%,/;[EMAIL PROTECTED]@|@g # [EMAIL PROTECTED]
Re: wtmp locking problem (was: Re: SOLVED: Erk! Something is *really* wrong here!)
On 8 Mar 1997, Guy Maor wrote: Karl Ferguson [EMAIL PROTECTED] writes: I agree. I've got login 1.45a-3 installed and the problem hasn't appeared - it's definately a problem in the rex-fixed/binary/base and bo/binary/base because if I dpkg -i *.deb in either directory the problem re-appears - if I then go back to original rex/binary/base it fixes it. As far as I know, the only other program that messes with wtmp in base is init. So could you just try the different versions of it? Now this IS the answer. I just downgraded one of my systems to sysvinit 2.69-1, rebooted, and the corruption seems to be gone. With sysvinig 2.70 I could produce the wtmp corruption at will just by doing killall getty. With sysvinit 2.69 this does not cause the corruption. I'll leave it running for a day or so before i'm completely convinced but this definitely looks like it's the answer. BTW, does anyone know of a way to restart init without rebooting? Maybe there should be a 'telinit R' option to force an 'exec /sbin/init'? craig
Re: wtmp locking problem (was: Re: SOLVED: Erk! Something is *really* wrong here!)
On 6 Mar 1997, Guy Maor wrote: Craig Sanders [EMAIL PROTECTED] writes: mgetty and telnet/ssltelnet trigger it because they call login. ssh wu-ftpd don't trigger it because they don't call login - they do their own thing. is that right? Correct. the more i think of it, the more it seems that there's a conflict between Set A and Set B login-related programs. Set A includes mgetty, telnet, getty, and other programs which call /bin/login. Set B includes ssh and wu-ftpd and other programs which do their own wtmp updating. Using only Set A programs on a system is fine. Using only Set B programs is fine too. Using both on the same system will cause the corruption. i think this is a more accurate summary of what is happening than what i posted last night. i think we should immediately change the login package so that it doesn't do this - at least until we know for sure how serious a problem it is and until we have time to update all relevant packages. I was looking for an explanation of this denial of service attack. Maybe I'm being obtuse, but I can't figure out how changing the location of the flock'd file changes the ability for somebody to lock it and prevent other logins. Surely it doesn't only apply if there's a world-writable wtmp? That would be silly. indeed! craig (30 today - according to my partner i am now officially a decrepit old geek rather than a young geek :-)
Re: wtmp locking problem (was: Re: SOLVED: Erk! Something is *really* wrong here!)
Craig Sanders: the more i think of it, the more it seems that there's a conflict between Set A and Set B login-related programs. Set A includes mgetty, telnet, getty, and other programs which call /bin/login. Set B includes ssh and wu-ftpd and other programs which do their own wtmp updating. Using only Set A programs on a system is fine. Using only Set B programs is fine too. Using both on the same system will cause the corruption. This doesn't explain why the problems have only started occurring in the past few days. I've been using the same set A/set B mix for many months, and only started getting corruption this week. Something must have changed, and that should be fixed. -- #!/usr/bin/perl -i\$q='$q',\$p='$p';eval\$q.\$\^I\n# # [EMAIL PROTECTED] $q='print$p$^I\n',$p='#!/usr/bin/perl -i';eval$q.$^I # Joey Hess He. He. He. - - Herman Toothrot
wtmp locking problem (was: Re: SOLVED: Erk! Something is *really* wrong here!)
(cross-posted to debian-user because there's a thread on this problem in there too) On 5 Mar 1997, Guy Maor wrote: It's a locking problem. From login's changelog: Version 1.45a (16-Dec-96) [...] Changed the wtmp locking scheme in login.c,agetty.c,simpleinit.c to flock() /etc/wtmplock instead of the wtmp file directly. This avoids a denial of service attack. Obviously a problem if others are not locking wtmp in the same fashion. rxvt does logging to wtmp, but strace reveals that it's locking /var/log/wtmp. init and other getty's are probably locking the actual wtmp file also. aha. that explains why there's a difference between my machines with modems and those without. the ones with modems get telnet, ssh, and agetty console logins as well as modem logins. The ones without modems generally only get xterm and ssh and ftpd logins but not console logins. mgetty and telnet/ssltelnet trigger it because they call login. ssh wu-ftpd don't trigger it because they don't call login - they do their own thing. is that right? Does anybody know anything about the denial of service attack? If serious, we'll have to change at least init, mgetty, rxvt. i think we should immediately change the login package so that it doesn't do this - at least until we know for sure how serious a problem it is and until we have time to update all relevant packages. i've patched pathnames.h and am trying it on one of my systems. I didn't read the source too closely, so i hope that just changing the lockfile path will fix the problem. --- pathnames.h.origFri Mar 7 02:39:22 1997 +++ pathnames.h Fri Mar 7 02:39:33 1997 @@ -35,4 +35,4 @@ #define _PATH_SINGLE /etc/singleboot #define _PATH_SECURE /etc/securesingle #define _PATH_USERTTY /etc/usertty -#define _PATH_WTMPLOCK /etc/wtmplock +#define _PATH_WTMPLOCK /var/log/wtmp craig [20 minutes later] damn. didn't work. i just installed my patched login getty. logged in, logged out, and then killall getty. I get five lines of corruption, one just after the logout, and one for each of the gettys running on that system. * Fri Mar 7 02:51 still logged in * Fri Mar 7 02:51 - 02:51 (00:00) * Fri Mar 7 02:51 - 02:51 (00:00) * Fri Mar 7 02:51 - 02:51 (00:00) * Fri Mar 7 02:51 - 02:51 (00:00) cas tty5 Fri Mar 7 02:51 - 02:51 (00:00) it's almost 3am and my brain isnt working very well any more. bed.