Re: wtmp locking problem (was: Re: SOLVED: Erk! Something is *really* wrong here!)

1997-03-20 Thread Ioannis Tambouras

 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!)

1997-03-08 Thread 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.

craig



Re: wtmp locking problem (was: Re: SOLVED: Erk! Something is *really* wrong here!)

1997-03-08 Thread Joey Hess
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!)

1997-03-08 Thread Craig Sanders

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!)

1997-03-07 Thread Craig Sanders

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!)

1997-03-07 Thread Joey Hess
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!)

1997-03-06 Thread Craig Sanders

(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.