jpd@usl-pc.usl.edu (DugalJP) (08/27/88)
A previous poster complained about unnecessary msgs sent to the console.
How does this rate in the unnecessary msgs category:
In OSx4.1 with QUOTAS installed, every time user exceeds his
quota, the msg "rwip: bn < 0, error 69"
appears on the console!
This was reported to RTOC; I've received no written answer yet.
--
-- James Dugal, N5KNX USENET: ...!{dalsqnt,killer}!usl!jpd
Associate Director Internet: jpd@usl.edu
Computing Center US Mail: PO Box 42770 Lafayette, LA 70504
University of Southwestern LA. Tel. 318-231-6417 U.S.A.steve@polyslo.CalPoly.EDU (Steve DeJarnett) (08/28/88)
In article <20@usl-pc.usl.edu> jpd@usl-pc.UUCP (DugalJP) writes: > >A previous poster complained about unnecessary msgs sent to the console. >How does this rate in the unnecessary msgs category: > In OSx4.1 with QUOTAS installed, every time user exceeds his > quota, the msg "rwip: bn < 0, error 69" > appears on the console! >This was reported to RTOC; I've received no written answer yet. We also see these messages (and in a University environment, you see people over quota quite often {especially when you have over 800 accounts with only 600 Meg of disk space for them}). I've talked to several people at RTOC, and all say that this is NOT considered a bug. Another annoying "feature", introduced in OSx4.4 is the fact that when there are bad login messages, they only report which tty the bad login occured on, and not what/who it was. I think (based on my experience) that if something doesn't crash your machine, they will try to fix it in the next MAJOR release (or when all of the programmers suddenly run out of things to do :-). If enough people complain, they'll try to do something about whatever your problem is. So, RTOC, are you listening??? ------------------------------------------------------------------------------- | Steve DeJarnett | Smart Mailers -> steve@polyslo.CalPoly.EDU | | Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve | | Cal Poly State Univ. |------------------------------------------------| | San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork | -------------------------------------------------------------------------------
hedrick@athos.rutgers.edu (Charles Hedrick) (08/30/88)
Well, I asked the developers about the "rwip: bn < 0, error 69", and they said "this is a debugging message that we didn't mean to leave in the release. You should just comment it out." Obviously that requires source (which we have). So it's clearly a bug. I don't mind having RTOC say it isn't worth fixing. It's a minor problem, though it could be serious if it causes real error messages to be missed. But to say it isn't a bug is certainly wrong. I've also been annoyed by the messages saying that someone is going over quota. Again, this is not really intentional. The problem is that they've got this code that prints a message whenever a process goes over quota. Usually it gets put on the controlling terminal for the user to see. But if the process doesn't have a controlling terminal, the console gets it. You can't just suppress all such messages on the console, because somebody might be using the console for real work, and go over quota. So there was no easy way to know when to print it and when not to. One could argue that if there's no user to see it, you should make sure that you alert the operator. But that argument is bogus: Since the message doesn't tell you who is over quota, there's nothing the operator can do about it. This is just another thing that happened to work that way and isn't serious enough to bother fixing.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (08/30/88)
steve@polyslo.calpoly.edu writes:
Another annoying "feature", introduced in OSx4.4
is the fact that when there are bad login messages, they only
report which tty the bad login occured on, and not what/who it was.
There is in fact at least one good reason for this. Sometimes people
make a mistake in their login sequence, and inadvertently type their
password at the login: prompt. Not only does it echo on their screen
for all those people looking over their shoulder to read, but if the
`login name' is logged as part of the BADLOGIN or BADREMOTE to the
console, then anyone in the machine room can see your password, too.
We don't own our entire machine room; other departments have equipment
in there, too, and one 98xe is in a semi-public Macintosh lab, guarded
only by the lab monitor on duty.
Since such a mistake is usually coupled with having already made a
mistake (login as root, mistype password, retype correct password at
next login:), it's pretty easy to correlate a pair BAD{LOGIN,REMOTE}
lines, one with a normal login name and one with seeming line noise.
Personally, I want to be able to configure whether or not the login
name appears in the BAD{LOGIN,REMOTE} messages. Stop hard-coding
these difficult choices.
--Karlsteve@polyslo.CalPoly.EDU (Steve DeJarnett) (08/31/88)
In article <20968@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >steve@polyslo.calpoly.edu writes: > Another annoying "feature", introduced in OSx4.4 > is the fact that when there are bad login messages, they only > report which tty the bad login occured on, and not what/who it was. > >There is in fact at least one good reason for this. Sometimes people >make a mistake in their login sequence, and inadvertently type their >password at the login: prompt. Not only does it echo on their screen >for all those people looking over their shoulder to read, but if the >`login name' is logged as part of the BADLOGIN or BADREMOTE to the >console, then anyone in the machine room can see your password, too. >We don't own our entire machine room; other departments have equipment >in there, too, and one 98xe is in a semi-public Macintosh lab, guarded >only by the lab monitor on duty. This is a valid point, but, for those of us who do own our machine room, it would be nice to be able to detect bad logins. Even nicer would be something like SunOS where it says something to the effect of: 'Repeated bad logins on tty?? as <whatever>' This would eliminate the case where Joe User typed his login and password in at the wrong times and having them show up on the console. This would also cut down on the number of these bad login messages that displace what might be 'real' problem messages on the console. >Personally, I want to be able to configure whether or not the login >name appears in the BAD{LOGIN,REMOTE} messages. Stop hard-coding >these difficult choices. Yes. If we can't have it the way I mentioned above, how about something like this. In a University environment, there are often a number of people who go around trying to get into other people's accounts by trying random passwords. I've been able to warn users in the past due to these messages on the console, but now all I know is that someone out there is trying to break into someones account, but I have no idea whose it is. I suppose I could check the log files (if those are even still maintained properly -- I don't know, as I haven't checked recently), but there should be some way to decide based on your own situation. > >--Karl ------------------------------------------------------------------------------- | Steve DeJarnett | Smart Mailers -> steve@polyslo.CalPoly.EDU | | Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve | | Cal Poly State Univ. |------------------------------------------------| | San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork | -------------------------------------------------------------------------------
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/04/88)
In article <3508@polyslo.CalPoly.EDU> steve@polyslo.UUCP (Steve DeJarnett) writes: >Even nicer would be something like SunOS where it says something to the >effect of: > > 'Repeated bad logins on tty?? as <whatever>' This is being done for the next (as yet unnumbered) OSx release. All system security and logging facilities and being integrated under syslog (dmesg goes away), which gives you an amazing amount of control over what's logged and what isn't. To be consistent, UUCP security and panic messages should go into syslog too (4.3BSD Tahoe does this), although I am vascilating over that one. I rather like the old ERRLOG file. <csg>