Lyris imminent
I asked [EMAIL PROTECTED] about Lyris on FreeBSD (the Linux version is in beta), saying I had heard that fbsd was more stable for heavy lifing. The response, to remain anonymous although I don't think my Deep Throat would mind being outed: quote We are using FreeBSD internally for Lyris development, and have been for about 6 months. We hope to release Lyris for FreeBSD in beta in the next few weeks. Yes, we find that freeBSD is more stable, and also faster than Linux. /quote Always comforting to prospects and lurkers to see high quality, commercial grade, top ranking packages being ported to FreeBSD. The above comment from someone so well placed in multi-platform development is golden. Great hacking, people! Len oh, how I wish Allaire would bring Cold Fusion to FreeBSD! ( CF/Linux port is announced ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 22:34:09 +0200, Mark Murray wrote: As long as the documentation is _clear_ that this is not a front-line security tool, but rather a thing to marginally augment logs with user-supplied info, then I'll buy it. This is why I put forward a motion to move pidentd out of security and into net / sysutils last year. The suggestion wasn't well received, but I still think it'd help. I'd also like for the DESCR file for the port to say: "This service offers remote users some identity to report back to the local admin when complaining about abuse / break-ins originating from the local host." Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Jon Ribbens wrote: Yuck. That's a complete abomination. What's the point of it? It's turning an out-of-memory situation from an easily-detected recoverable temporary resource shortage which can be worked-around or waited out, into an unrecoverable fatal error. Do a significant number of programs really request memory which they then proceed not to use? That's *not* abomination. How about pre-allocating over 100 Mb for X Free, for instance? Basically, if you don't have enough memory, you just don't have enough memory. What FreeBSD does *reduces* the need for memory. If FreeBSD *did not* do it, then you'd need much more memory. If the system runs out of memory, the biggest process is killed. It might or might not be the one demanding additional memory. No, if the *process* hits its *administrative* resource limits. i.e. setrlimit(2). Ah, that's another matter entirely. Then, malloc() returns an error indeed. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] I'm one of those bad things that happen to good people. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. This seems like a very Linuxy development trend. It's the way the Bazaar works, but not in a Cathedral. Rather, you have a look at what's already there and try to work on it. You don't start your own wing a few feet from the Cathedral in the hopes that someone will bash down a similar wing elsewhere and join yours to the main building. Waffle waffle. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
KLD documentation
Some hacking group has written an introduction to using KLDs under FreeBSD. It's not supposed to be a "normal" tutorial, but it may be appreciated by a few people on this list. http://thc.pimmel.com/files/thc/bsdkern.html -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
WaveLAN problem
I have a WaveLAN ISA adaptor. I am trying to run it in a machine equiped with an AMD K6-2 350 processor running at 66mhz bus speed. I am getting the following error while ifconfiging the card. ifconfig wl0 192.168.10.1 ifconfig: ioctl (SIOCAIFADDR): File exists cray100 /root 2% Jul 12 03:43:23 cray100 /kernel: wl0: diag() failed; status = 0, inw = 0, outw = e0a0 Jul 12 03:43:23 cray100 /kernel: wl0: diag() failed; status = 0, inw = 0, outw = e0a0 Jul 12 03:43:23 cray100 /kernel: scb_status a000 Jul 12 03:43:23 cray100 /kernel: scb_status a000 Jul 12 03:43:23 cray100 /kernel: scb_command 0 Jul 12 03:43:23 cray100 /kernel: scb_command 0 Jul 12 03:43:23 cray100 /kernel: scb_cbl ffc0 Jul 12 03:43:23 cray100 /kernel: scb_cbl ffc0 Jul 12 03:43:23 cray100 /kernel: cu_cmd 8007 Jul 12 03:43:23 cray100 /kernel: cu_cmd 8007 Jul 12 03:43:23 cray100 /kernel: wl0 init(): trouble resetting board. Jul 12 03:43:23 cray100 /kernel: wl0 init(): trouble resetting board. I belive the issure is some kind of timeing problem because the dos drivers and ptpdiag work and the card works with freebsd in other machines. I have tried about everything I can think of I have set machdep.wl_xmit_delay: up and down as well as played with clock speeds of the CPU and motherboard as well as bios wait states, pnp settings ect. and differant wavelan cards. I even reset the factory setting off 0x300 irq 10 to other ones just to be sure.. I have tried the drivers in 3.0 3.1 and 4.0 current they all do the same thing.. thease are the current dmesg settings wl0 at 0x390-0x39f irq 5 on isa wl0: address 08:00:6a:2b:e3:30, NWID 0x5262, Freq 2422 MHz and the wlconfig info... cray100 /root 6% wlconfig wl0 Board type: ISA Base address options : 0x300, 0x390, 0x3c0, 0x3e0 Waitstates: 0 Bus mode : ISA IRQ : 5 Default MAC address : 08:00:6a:2b:e3:30 Soft MAC address : 00:00:00:00:00:00 Current MAC address : Default Adapter compatability : PCCARD or 1/2 size AT, 915MHz or 2.4GHz Threshold preset : 1 Call code required: NO Subband : 915MHz/see WaveModem Quality threshold : 3 Hardware version : 1 (Rel3) Network ID enable : YES NWID : 0x5262 Datalink security : NO Databus width : 16 (variable) Configuration state : unconfigured CRC-16: 0xaba1 CRC status: OK If anyone can help in any way or point me to someone who might I would greatly apreciate it. Thanks in advance Richard Puga [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Yuck. That's a complete abomination. What's the point of it? It's turning Paging Terry Lambert, Terry Lambert - do you read me? It's time for your annual rant on the topic of memory overcommit. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
(forw)
Have you all seen this? -- Reverse engineering, the most phun and usually the most effective way to tackle a problem or learn something new. Public PGP key: http://www.ecad.org/crypt0genic_pgp_key Website:http://www.ecad.org/ Hi folks, THC released a new article dealing with FreeBSD 3.x Kernel modules that can attack/backdoor the system. You can find our article on http://thc.pimmel.com or http://r3wt.base.org. Greets, pragmatic / The Hacker's Choice
Re: (forw)
Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? -Kp crypt0genic wrote: Have you all seen this? From: Anonymous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi folks, THC released a new article dealing with FreeBSD 3.x Kernel modules that can attack/backdoor the system. You can find our article on http://thc.pimmel.com or http://r3wt.base.org. Greets, pragmatic / The Hacker's Choice To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (forw)
Karl Pielorz wrote: Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? Garbage. You can do this on any OS, whether it supports loadable modules or not, if you've managed to win sufficient privileges through some other means. FreeBSD (and other OSs with loadable module support) merely provides a well-defined API which, like almost every other well- defined API, can be abused by those who harbor ill-will. Making the interface "complicated" does absolutely nothing to stop script-kiddies: Once a complicated interface is in an exploit script, who cares how arcane it is? - mark Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Keyboard mappings ...
On Mon, Jul 12, 1999 at 11:50:33AM -0300, The Hermit Hacker wrote: Attached is the output of 'tconv -b vt221' on our Solaris machine where this map'ng is required, but the output doesn't look anything like /etc/termcap :( Try doing "infocmp -C vt221" to get termcap output. What you have is terminfo. If you really want to understand terminfo, look at ncurses. -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/12578: `` subshell taints PWD
Hi folks, I'm hoping someone here is interested in tracking down a bug in our /bin/sh . Changing directory within a backtick (``) subshell in sh taints the parent's working directory. The following sample code gives the expected result for /bin/csh, but breaks for /bin/sh cd /tmp echo .`cd /`. pwd Any takers? Ciao, Sheldon. PS: And no, this is not an invitation to chat about the default shell for the base system. :-) PPS: S! PPPS: www.s.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Keyboard mappings ...
Beautiful...thanks :) Infocmp doesn't exist under FreeBSD, but Solaris
has it :)
On Mon, 12 Jul 1999, Dominic Mitchell wrote:
On Mon, Jul 12, 1999 at 11:50:33AM -0300, The Hermit Hacker wrote:
Attached is the output of 'tconv -b vt221' on our Solaris machine
where this map'ng is required, but the output doesn't look anything like
/etc/termcap :(
Try doing "infocmp -C vt221" to get termcap output. What you have is
terminfo. If you really want to understand terminfo, look at ncurses.
--
Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator
In Mountain View did Larry Wall
Sedately launch a quiet plea:
That DOS, the ancient system, shall
On boxes pleasureless to all
Run Perl though lack they C.
--
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
**
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
keymapping continued ...
Morning...
Got a couple of suggestions, and have tried both, with the
xkeycaps appearing to be the more practical for what I'm trying to get
done, I think.
From reading the xkeycaps man page, its a frontend for xmodmap,
but reading *its* man page pretty much got me nowhere fast, so I'm going
to try again with an example, as it might be that I'm just missing
something...
I need to build a keyboard map such that:
F1 == ESC OP
F2 == ESC OQ
Shift-F1 == ESC [31~
Shift-F2 == ESC [32~
Now, in xkeycaps, it allows me to "remap" keys but gives you a
fixed list of what it wants.
Now, looking at the output of the infocmp command someone
previously suggested for going from terminfo-termcap, I can see the
sequences:
k1=\EOP
Which says that F1 sends out \EOP (ESC OP)
Now, if I add the vt221 entry generated by infocmp, do a 'set
term' and telnet over to the remote host where I need to run the app, and
do a 'set term' over there, and hit 'F1', it generates ESC [11~ instead of
the ESC OP that I'm trying to tell it to send...
So, I'm guessing that I have to do an 'xmodmap' vs a termcap
entry?
If so, how would I build up the above? I need to do F1-F12 +
Shift_F1-Shift_F12 for this to be feasible.
If I have to install some sort of 'terminal package' for him to be
able to do this, this is acceptable, we just need to get the map'ngs
themselves working...
Hopefully this makes a bit more sense?
Thanks...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: keymapping continued ...
On Mon, 12 Jul 1999 15:04:43 -0300, The Hermit Hacker wrote: Hopefully this makes a bit more sense? What doesn't make sense is the fact that a FreeBSD developer, who should know better, is mailing this sort of thing to freebsd-hackers. Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: keymapping continued ...
In message [EMAIL PROTECTED] The Hermit Hacker writes: : I need to build a keyboard map such that: : : F1 == ESC OP : F2 == ESC OQ : Shift-F1 == ESC [31~ : Shift-F2 == ESC [32~ Why not do this with Xterm translations? Generally speaking xmodmap and friends are poor choices to even think about doing this with since they don't translate function keys to escape sequences. The applications do that, if they want. The only time you're likely to need them is in a terminal emulation situation, which makes xterm the logical place to do this. : Hopefully this makes a bit more sense? Yes. It does. You should use the translations resource for XTerm to accomplish this. From my .Xdefaults file: XTerm*vt100*translations: #override \n\ Alt KeyPress y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\ Meta KeyPress y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\ KeyPress BackSpace: string( 0x7f )\n is one example. It allows me to "map" the BackSpace key into a DEL character (which in my religion is the right thing to do, your religion might vary), as well as giving me an easy way to paste, at least into xterms when I don't have a middle mouse button. This could easily be expanded to include all the vt220 keys that your boss/coworker needs in xterm. Check out the xterm man page for a more complete example, including ways of mapping different keymaps at the touch of a key. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: keymapping continued ...
On Mon, 12 Jul 1999, Sheldon Hearn wrote:
On Mon, 12 Jul 1999 15:04:43 -0300, The Hermit Hacker wrote:
Hopefully this makes a bit more sense?
What doesn't make sense is the fact that a FreeBSD developer, who should
know better, is mailing this sort of thing to freebsd-hackers.
You know what I always love? someone telling another they posted to the
wrong place without taking the second to tell them a better place to post
it...almost as bad as posting to the wrong place in the first place, and
more of a waste of bandwidth...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Mon, 12 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. This seems like a very Linuxy development trend. It's the way the Bazaar works, but not in a Cathedral. Rather, you have a look at what's already there and try to work on it. You don't start your own wing a few feet from the Cathedral in the hopes that someone will bash down a similar wing elsewhere and join yours to the main building. It's "out with the bad, in with the good." Pidentd code is pretty terrible. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. But frankly, I highly doubt anyone will find anything to exploit. And, why would bugtraq advisories against other identds apply to my ident_stream service? This is an entirely different code base. Waffle waffle. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: keymapping continued ...
Okay, slowly getting somewhere, I think...
We setup the .Xdefaults file, as follows, on the remote server and are
starting an xterm to the client machine, which is "acceptable", but I must
be missing something:
XTerm*vt100*translations: #override \n\
Shift KeyPress F1:string(0x1B) string(0x5B) string(0x33) string(0x33)
string(0x7E)\n\
KeyPress F1:string(0x1B) string(0x4F) string(0x50)\n\
Shift KeyPress F5:string(0x1B) string(0x5B) string(0x33) string(0x35)
string(0x7E)\n\
KeyPress F5:string(0x1B) string(0x5B) string(0x31) string(0x36)
string(0x7E)\n
Now, when I press 'Shift F5', I get [35~ showing up on the app, but its as if
the ESC didn't go through...
Is there a better way I should be writing this? I'm going by the example it
showed for sending "multiple characters", but there might be another function
I should be using for this?
The neat thing is that the F5 one worked fine, its only the 'Shift F5' one so
far that isn't...
Thanks...
On Mon, 12 Jul 1999, The Hermit Hacker wrote:
Perfect, slowly putting it together. One thing that I didn't find in the
man page, and am wondering if its just somethign I did wrong, but does
ordering matter?
I put in, first time through:
KeyPress F1: ...
Shift KeyPress F1: ...
And it Shift-F1 and F1 both gave the same answers...
But, if I reverse it, it works as expected/hoped...
Mistake on my part, or normal?
thanks...
On Mon, 12 Jul 1999, Warner Losh wrote:
In message [EMAIL PROTECTED]
The Hermit Hacker writes:
: I need to build a keyboard map such that:
:
: F1 == ESC OP
: F2 == ESC OQ
: Shift-F1 == ESC [31~
: Shift-F2 == ESC [32~
Why not do this with Xterm translations? Generally speaking xmodmap
and friends are poor choices to even think about doing this with since
they don't translate function keys to escape sequences. The
applications do that, if they want. The only time you're likely to
need them is in a terminal emulation situation, which makes xterm the
logical place to do this.
: Hopefully this makes a bit more sense?
Yes. It does. You should use the translations resource for XTerm to
accomplish this. From my .Xdefaults file:
XTerm*vt100*translations: #override \n\
Alt KeyPress y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\
Meta KeyPress y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\
KeyPress BackSpace: string( 0x7f )\n
is one example. It allows me to "map" the BackSpace key into a DEL
character (which in my religion is the right thing to do, your
religion might vary), as well as giving me an easy way to paste, at
least into xterms when I don't have a middle mouse button.
This could easily be expanded to include all the vt220 keys that your
boss/coworker needs in xterm.
Check out the xterm man page for a more complete example, including
ways of mapping different keymaps at the touch of a key.
Warner
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: (forw)
On Mon, 12 Jul 1999, Karl Pielorz wrote: Mark Newton wrote: Karl Pielorz wrote: Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? Garbage. You can do this on any OS, whether it supports loadable modules or not, if you've managed to win sufficient privileges through some other means. I was actually leaning towards that... My boss had kittens here (we have 12 FreeBSD boxes running the show now), until I'd explained it to him... If syscall's need to be replaced, they need to be replaced - and if they are replaceable ... (I'll stop there) :) The article (from what I can remember) didn't actually go out of it's way to say you have to have be root to load the modules in the first place :) - Maybe it's warrants some kind of response page putting up somewhere? - this is also getting off topic for -hackers :(... It was mentioned when describing the conditions for allowing the file load (securelevel == 0 uid == 0). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (forw)
I would suggest that a version of this document be incorporated into our docs. It's not like it says anythign new, but it's a really good introduction to KLD modules and maybe it's be better to have those documents around to remind people how easy it is to hack a system once root is broken. julian On Mon, 12 Jul 1999, Karl Pielorz wrote: Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? -Kp crypt0genic wrote: Have you all seen this? From: Anonymous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi folks, THC released a new article dealing with FreeBSD 3.x Kernel modules that can attack/backdoor the system. You can find our article on http://thc.pimmel.com or http://r3wt.base.org. Greets, pragmatic / The Hacker's Choice To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: more amd hangs
On Fri, 9 Jul 1999, Doug wrote:
In my continuing efforts to get this freebsd box into shape for
web hosting at my company (where it relies exclusively on NFS for
retrieving customer data) I've been making progress thanks to some recent
commits by Peter. Now I can run the heavy duty NFS access script and it
completes its mission about 2 out of 3 times. Also, now when it fails it
doesn't lock the whole box, just amd. Still not where I want it to be, but
it is definitely big progress. :)
What happens when it hangs is that amd becomes totally wedged. I
cannot do 'df' or 'ls /' at all (the amd mountpoints are on /), and
killing the amd process is no help; I have to reboot the box. Ktrace'ing
amd at this point gets me nothing. The ktrace process just dies and leaves
a 0 byte ktrace.out file. (BTW, I am also still having problems with
ktrace exiting while the process is still running when I actually get it
to attach, if anyone cares.)
Still working on this problem. Thanks to some suggestions I got
off the list, I have compiled libc and amd with debugging symbols. I
wedged the box the same way I have previously, by running a perl script
that automounts a directory, reads 250 files in that directory, automounts
another one, etc. for a total of 68 directories.
Using today's current this time amd wedged in the following state
according to top:
155 root3 0 736K 520K siobi 1 0:21 0.00% 0.00% amd
Here is the trace after killing it:
Core was generated by `amd'.
Program terminated with signal 3, Quit.
#0 0x8063dc4 in open ()
(gdb) where
#0 0x8063dc4 in open ()
#1 0x806b5c3 in vsyslog (pri=6, fmt=0x809279a "%s", ap=0xbfbfd2c0 "")
at /usr/src/lib/libc/../libc/gen/syslog.c:262
#2 0x806b2c2 in syslog (pri=6, fmt=0x809279a "%s")
at /usr/src/lib/libc/../libc/gen/syslog.c:130
#3 0x805a3d8 in real_plog (lvl=6,
fmt=0x8091440 "prime_nfs_fhandle_cache: NFS version %d",
vargs=0xbfbfdafc "\002")
at
/usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:443
#4 0x805a2be in plog (lvl=16,
fmt=0x8091440 "prime_nfs_fhandle_cache: NFS version %d")
at
/usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:383
#5 0x805323a in prime_nfs_fhandle_cache (path=0x80cb287
"/Space/209.132.66",
fs=0x80b5640, fhbuf=0xbfbfdb34, wchan=0x80b57c0)
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/ops_nfs.c:262
#6 0x805363f in nfs_init (mf=0x80b57c0)
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/ops_nfs.c:542
#7 0x804a7f9 in amfs_auto_bgmount (cp=0x80c8600, mpe=0)
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amfs_auto.c:676
#8 0x804a4bc in amfs_auto_retry (rc=0, term=0, closure=0x80c8600)
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amfs_auto.c:402
#9 0x8055212 in do_task_notify ()
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/sched.c:239
#10 0x804df6d in softclock ()
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:212
#11 0x8052583 in run_rpc ()
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:253
#12 0x80527e6 in mount_automounter (ppid=154)
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:467
#13 0x804a109 in main (argc=4, argv=0xbfbfddec)
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amd.c:544
#14 0x80480e9 in _start ()
I'm going to work on attaching it with gdb while it's locked next.
Also based on advice I've made some changes to my configuration
files, although it didn't help the 'ls /' or 'df' problems.
Thanks for any help,
Doug
--
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers
[ global ]
# Only search for maps of this type
map_type = file
# Search this path for maps
search_path =/etc
# Use this directory for amd's private mount points
auto_dir = /usr/amd/realmounts
# Log all activity to syslog (daemon)
log_file = syslog:local7
log_options =all
# Check /etc/hosts for hostnames
normalize_hostnames = yes
# Lock the amd process into memory, improves perf.
plock = yes
# Use the special /default entry in maps
selectors_on_default = yes
# DEFINE AN AMD MOUNT POINT
[ /usr/amd/Interfaces ]
map_name = amd.Interfaces
[ /usr/amd/Hold ]
map_name = amd.Hold
32# more /etc/amd.Interfaces
/defaults type:=nfs;opts:=rw,vers=2,intr,proto=udp,noconn
209.132.4 netapp01:/vol/Space/209.132.4
* rhost:=IP${key};rfs:=/Space/${key}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: (forw)
On Mon, 12 Jul 1999, Doug Rabson wrote: On Mon, 12 Jul 1999, Karl Pielorz wrote: Mark Newton wrote: Karl Pielorz wrote: Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? Garbage. You can do this on any OS, whether it supports loadable modules or not, if you've managed to win sufficient privileges through some other means. I was actually leaning towards that... My boss had kittens here (we have 12 FreeBSD boxes running the show now), until I'd explained it to him... If syscall's need to be replaced, they need to be replaced - and if they are replaceable ... (I'll stop there) :) The article (from what I can remember) didn't actually go out of it's way to say you have to have be root to load the modules in the first place :) - Maybe it's warrants some kind of response page putting up somewhere? - this is also getting off topic for -hackers :(... It was mentioned when describing the conditions for allowing the file load (securelevel == 0 uid == 0). which suggests that most important servers should be run whith securelevel 0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: hardware
On Fri, 9 Jul 1999, Jake Burkholder wrote: Nvidia cards are already supported. The GL xlock savers look awesome. Really? Wow. The xscreensaver GL savers looked like crap, the xlockmore ones worked for about oh two seconds, before slowing down to unaccelerated speeds. This at 640x480x16 too. Hmm. At least 2D works great at 1152x864x32. - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCCARD and Vpp voltage
Warner Losh wrote: In message [EMAIL PROTECTED] Wes Peters writes: : It shouldn't be all that hard to read the register and set the voltages : appropriately. Table 5-1 on p. 54 has the PC Card register values for : CVS[2:1] and what they mean. Agreed... : Quatech or Socket Communications? I don't see one right off. Socket. I'm going for the low power ruggedized one, unless I can find something better to use. But that's for my PDA so I can NFS mount a root file system after the kernel has booted. I wish I had more CF slots on this beast Time to build a CF expansion cage? Or, better yet, a CF to PCCard cage? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: more amd hangs
Ok, it's now wedged in a different state (using the same perl script to wedge it). According to top: 317 root2 0 648K 456K STOP 0 0:00 0.00% 0.00% amd I also managed to attach to the running process this time: (gdb) file /usr/sbin/amd Reading symbols from /usr/sbin/amd...done. (gdb) attach 317 Attaching to program: /usr/sbin/amd, process 317 0x8063c34 in select () (gdb) where #0 0x8063c34 in select () #1 0x80523b6 in do_select (smask=0, fds=1024, fdp=0xbfbfd990, tvp=0xbfbfd984) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:146 #2 0x80525fd in run_rpc () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:274 #3 0x80527e6 in mount_automounter (ppid=316) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:467 #4 0x804a109 in main (argc=1, argv=0xbfbfdb84) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amd.c:544 #5 0x80480e9 in _start () I am noticing that the last function, _start() is the same as in the last traceback. Anyone with suggestions, I'm open to them. :) I tried doing 'continue' with gdb and it wedged gdb and amd, so I just rebooted. HTH, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: more amd hangs
On 10 Jul 1999 12:56:41 -0400, R. Matthew Emerson wrote: I thought that it was almost never proper to soft-mount rw filesytems. Am I mistaken about this? I must admit, it sounds like sensible advice. The only NFS exports which I have to rely on are read-only mounts. The only time I soft-mounted a read-write export was when I was mucking around with buildworld over NFS, and it didn't cause me problems then. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: more amd hangs: in _start()
Ok, got another hang in "siobi" state (this time after it successfully completed the script). Here is the trace: (gdb) file /usr/sbin/amd Reading symbols from /usr/sbin/amd...done. (gdb) attach 155 Attaching to program: /usr/sbin/amd, process 155 0x8063dc4 in open () (gdb) where #0 0x8063dc4 in open () #1 0x806b5c3 in vsyslog (pri=6, fmt=0x809279a "%s", ap=0xbfbfb240 "X") at /usr/src/lib/libc/../libc/gen/syslog.c:262 #2 0x806b2c2 in syslog (pri=6, fmt=0x809279a "%s") at /usr/src/lib/libc/../libc/gen/syslog.c:130 #3 0x805a3d8 in real_plog (lvl=6, fmt=0x8091ea0 "recompute_portmap: NFS version %d", vargs=0xbfbfba7c "\002") at /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:443 #4 0x805a2be in plog (lvl=16, fmt=0x8091ea0 "recompute_portmap: NFS version %d") at /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:383 #5 0x80556f8 in recompute_portmap (fs=0x80c9f80) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/srvr_nfs.c:285 #6 0x80559ff in nfs_srvr_port (fs=0x80c9f80, port=0xbfbfbabe, wchan=0x0) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/srvr_nfs.c:564 #7 0x80534cd in call_mountd (fp=0xbfbfdb24, proc=3, f=0, wchan=0x0) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/ops_nfs.c:438 #8 0x8053a3d in nfs_umounted (mp=0x80cad00) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/ops_nfs.c:796 #9 0x804dd4f in am_unmounted (mp=0x80cad00) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/autil.c:366 #10 0x8050b22 in free_map_if_success (rc=0, term=0, closure=0x80cad00) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/map.c:924 #11 0x8055212 in do_task_notify () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/sched.c:239 #12 0x804df6d in softclock () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:212 #13 0x8052583 in run_rpc () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:253 #14 0x80527e6 in mount_automounter (ppid=154) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:467 #15 0x804a109 in main (argc=4, argv=0xbfbfddec) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amd.c:544 #16 0x80480e9 in _start () I'm going to have a go at the code now that I can be fairly certain that _start() is the culprit. (Please everyone, stop laughing, thanks. :) Comments or suggestions welcome. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
On Mon, 12 Jul 1999 23:56:29 +0100, Jon Ribbens wrote: What about it? If an application does not need 100MB, it should not malloc it. If it does need it, it should malloc it and know that it is available if the malloc succeeds. You're rehashing stuff that's been discussed to death. Please look at the mailing list archives for this mailing list. If you're not prepared to do that, the long and the short of it is that FreeBSD _does_ overcommit, we like it that way and neither of these two facts is likely to change. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Sheldon Hearn [EMAIL PROTECTED] wrote: You're rehashing stuff that's been discussed to death. Please look at the mailing list archives for this mailing list. I'd love to, could you please be more specific? I can't find anything relevant searching for 'malloc' or 'overcommit'. If you're not prepared to do that, the long and the short of it is that FreeBSD _does_ overcommit, we like it that way and neither of these two facts is likely to change. I can add it to the list of reasons I don't use it then I guess ;-). Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Yuck. That's a complete abomination. What's the point of it? It's turning Paging Terry Lambert, Terry Lambert - do you read me? It's time for your annual rant on the topic of memory overcommit. :-) It's not overcommit so much as it is what happens to a process that gets a page fault when there are no available pages to 'fix up' the overcommit. AIX began overcommitting at one point but would kill -9 any process that page faulted when there were no available pages. AIX sysadmins universally hated this behavior and allocated HUGE swap files to avoid it. I assume FreeBSD does something more reasonable. Todd Whitesel toddpw @ best.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Jon Ribbens wrote: If you're not prepared to do that, the long and the short of it is that FreeBSD _does_ overcommit, we like it that way and neither of these two facts is likely to change. I can add it to the list of reasons I don't use it then I guess ;-). Whatever. The operating system you use also does it. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] I'm one of those bad things that happen to good people. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Compromising a FreeBSD from inside (was: (forw))
People, how much attention are you going to get to this topic with a subject line like "(forw)"? On Monday, 12 July 1999 at 12:28:03 +, crypt0genic wrote: Have you all seen this? To: [EMAIL PROTECTED] Hi folks, THC released a new article dealing with FreeBSD 3.x Kernel modules that can attack/backdoor the system. You can find our article on http://thc.pimmel.com or http://r3wt.base.org. For those of us who *hate* incorrect or approximate URLs, try http://thc.pimmel.com/files/thc/bsdkern.html. Greets, pragmatic / The Hacker's Choice On Monday, 12 July 1999 at 21:19:45 +0930, Mark Newton wrote: Karl Pielorz wrote: Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? Garbage. You can do this on any OS, whether it supports loadable modules or not, if you've managed to win sufficient privileges through some other means. FreeBSD (and other OSs with loadable module support) merely provides a well-defined API which, like almost every other well- defined API, can be abused by those who harbor ill-will. Making the interface "complicated" does absolutely nothing to stop script-kiddies: Once a complicated interface is in an exploit script, who cares how arcane it is? In fact, the most interesting thing about this (rather large) document is that it's the best documentation I've seen on klds. I don't know why anybody would want to use it for compromising security, since it's a *lot* of work, and to even get as far as installing it you have to be root already, so you would have plenty of easier alternatives. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Compromising a FreeBSD from inside (was: (forw))
On Tue, 13 Jul 1999, Greg Lehey wrote: In fact, the most interesting thing about this (rather large) document is that it's the best documentation I've seen on klds. I don't know why anybody would want to use it for compromising security, since it's a *lot* of work, and to even get as far as installing it you have to be root already, so you would have plenty of easier alternatives. It's more for hiding yourself once you're already in; if you load a module at boot-time which hides the fact that it was loaded, hides the module itself from being listed by the filesystem syscalls, and hides whatever else you want, you could presumably stay hidden a lot easier. Kris - "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Lyris imminent
I asked supp...@lyris.com about Lyris on FreeBSD (the Linux version is in beta), saying I had heard that fbsd was more stable for heavy lifing. The response, to remain anonymous although I don't think my Deep Throat would mind being outed: quote We are using FreeBSD internally for Lyris development, and have been for about 6 months. We hope to release Lyris for FreeBSD in beta in the next few weeks. Yes, we find that freeBSD is more stable, and also faster than Linux. /quote Always comforting to prospects and lurkers to see high quality, commercial grade, top ranking packages being ported to FreeBSD. The above comment from someone so well placed in multi-platform development is golden. Great hacking, people! Len oh, how I wish Allaire would bring Cold Fusion to FreeBSD! ( CF/Linux port is announced ) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 22:34:09 +0200, Mark Murray wrote: As long as the documentation is _clear_ that this is not a front-line security tool, but rather a thing to marginally augment logs with user-supplied info, then I'll buy it. This is why I put forward a motion to move pidentd out of security and into net / sysutils last year. The suggestion wasn't well received, but I still think it'd help. I'd also like for the DESCR file for the port to say: This service offers remote users some identity to report back to the local admin when complaining about abuse / break-ins originating from the local host. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Jon Ribbens wrote: Yuck. That's a complete abomination. What's the point of it? It's turning an out-of-memory situation from an easily-detected recoverable temporary resource shortage which can be worked-around or waited out, into an unrecoverable fatal error. Do a significant number of programs really request memory which they then proceed not to use? That's *not* abomination. How about pre-allocating over 100 Mb for X Free, for instance? Basically, if you don't have enough memory, you just don't have enough memory. What FreeBSD does *reduces* the need for memory. If FreeBSD *did not* do it, then you'd need much more memory. If the system runs out of memory, the biggest process is killed. It might or might not be the one demanding additional memory. No, if the *process* hits its *administrative* resource limits. i.e. setrlimit(2). Ah, that's another matter entirely. Then, malloc() returns an error indeed. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. This seems like a very Linuxy development trend. It's the way the Bazaar works, but not in a Cathedral. Rather, you have a look at what's already there and try to work on it. You don't start your own wing a few feet from the Cathedral in the hopes that someone will bash down a similar wing elsewhere and join yours to the main building. Waffle waffle. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: rtfm rewritten in C (updated)
On Sun, 11 Jul 1999 22:00:04 EST, Chris Costello wrote: As usual, it's at http://www.calldei.com/~chris/rtfm.tar.gz Can I suggest that you make a port of your little project so that you don't have to announce updates to hackers every few days? Those who're interested will see CVS commit messages for your port. I'd suggest category misc. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
KLD documentation
Some hacking group has written an introduction to using KLDs under FreeBSD. It's not supposed to be a normal tutorial, but it may be appreciated by a few people on this list. http://thc.pimmel.com/files/thc/bsdkern.html -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
WaveLAN problem
I have a WaveLAN ISA adaptor. I am trying to run it in a machine equiped with an AMD K6-2 350 processor running at 66mhz bus speed. I am getting the following error while ifconfiging the card. ifconfig wl0 192.168.10.1 ifconfig: ioctl (SIOCAIFADDR): File exists cray100 /root 2% Jul 12 03:43:23 cray100 /kernel: wl0: diag() failed; status = 0, inw = 0, outw = e0a0 Jul 12 03:43:23 cray100 /kernel: wl0: diag() failed; status = 0, inw = 0, outw = e0a0 Jul 12 03:43:23 cray100 /kernel: scb_status a000 Jul 12 03:43:23 cray100 /kernel: scb_status a000 Jul 12 03:43:23 cray100 /kernel: scb_command 0 Jul 12 03:43:23 cray100 /kernel: scb_command 0 Jul 12 03:43:23 cray100 /kernel: scb_cbl ffc0 Jul 12 03:43:23 cray100 /kernel: scb_cbl ffc0 Jul 12 03:43:23 cray100 /kernel: cu_cmd 8007 Jul 12 03:43:23 cray100 /kernel: cu_cmd 8007 Jul 12 03:43:23 cray100 /kernel: wl0 init(): trouble resetting board. Jul 12 03:43:23 cray100 /kernel: wl0 init(): trouble resetting board. I belive the issure is some kind of timeing problem because the dos drivers and ptpdiag work and the card works with freebsd in other machines. I have tried about everything I can think of I have set machdep.wl_xmit_delay: up and down as well as played with clock speeds of the CPU and motherboard as well as bios wait states, pnp settings ect. and differant wavelan cards. I even reset the factory setting off 0x300 irq 10 to other ones just to be sure.. I have tried the drivers in 3.0 3.1 and 4.0 current they all do the same thing.. thease are the current dmesg settings wl0 at 0x390-0x39f irq 5 on isa wl0: address 08:00:6a:2b:e3:30, NWID 0x5262, Freq 2422 MHz and the wlconfig info... cray100 /root 6% wlconfig wl0 Board type: ISA Base address options : 0x300, 0x390, 0x3c0, 0x3e0 Waitstates: 0 Bus mode : ISA IRQ : 5 Default MAC address : 08:00:6a:2b:e3:30 Soft MAC address : 00:00:00:00:00:00 Current MAC address : Default Adapter compatability : PCCARD or 1/2 size AT, 915MHz or 2.4GHz Threshold preset : 1 Call code required: NO Subband : 915MHz/see WaveModem Quality threshold : 3 Hardware version : 1 (Rel3) Network ID enable : YES NWID : 0x5262 Datalink security : NO Databus width : 16 (variable) Configuration state : unconfigured CRC-16: 0xaba1 CRC status: OK If anyone can help in any way or point me to someone who might I would greatly apreciate it. Thanks in advance Richard Puga p...@mauibuilt.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Yuck. That's a complete abomination. What's the point of it? It's turning Paging Terry Lambert, Terry Lambert - do you read me? It's time for your annual rant on the topic of memory overcommit. :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
(forw)
Have you all seen this? -- Reverse engineering, the most phun and usually the most effective way to tackle a problem or learn something new. Public PGP key: http://www.ecad.org/crypt0genic_pgp_key Website:http://www.ecad.org/ ---BeginMessage--- Hi folks, THC released a new article dealing with FreeBSD 3.x Kernel modules that can attack/backdoor the system. You can find our article on http://thc.pimmel.com or http://r3wt.base.org. Greets, pragmatic / The Hacker's Choice ---End Message---
Re: (forw)
Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? -Kp crypt0genic wrote: Have you all seen this? From: Anonymous nob...@replay.com To: bugt...@securityfocus.com Hi folks, THC released a new article dealing with FreeBSD 3.x Kernel modules that can attack/backdoor the system. You can find our article on http://thc.pimmel.com or http://r3wt.base.org. Greets, pragmatic / The Hacker's Choice To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: (forw)
Karl Pielorz wrote: Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? Garbage. You can do this on any OS, whether it supports loadable modules or not, if you've managed to win sufficient privileges through some other means. FreeBSD (and other OSs with loadable module support) merely provides a well-defined API which, like almost every other well- defined API, can be abused by those who harbor ill-will. Making the interface complicated does absolutely nothing to stop script-kiddies: Once a complicated interface is in an exploit script, who cares how arcane it is? - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: (forw)
Mark Newton wrote: Karl Pielorz wrote: Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? Garbage. You can do this on any OS, whether it supports loadable modules or not, if you've managed to win sufficient privileges through some other means. I was actually leaning towards that... My boss had kittens here (we have 12 FreeBSD boxes running the show now), until I'd explained it to him... If syscall's need to be replaced, they need to be replaced - and if they are replaceable ... (I'll stop there) :) The article (from what I can remember) didn't actually go out of it's way to say you have to have be root to load the modules in the first place :) - Maybe it's warrants some kind of response page putting up somewhere? - this is also getting off topic for -hackers :(... -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
misc/3237 (adding SCRIPTS to bsd.prog.mk)
Does anyone feel strongly about the small patch in misc/3237 to add support for handling installation of script files in bsd.prog.mk? I can certainly see how this could be useful. Kris - Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes. -- Unknown To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Keyboard mappings ...
Morning...
Last week, at work, I talked one of the guys in IS into switching
from using Win98 to using FreeBSD 3.2/X, and all has gone well so far,
except that we've hit a snag that I'm not sure how to rectify...
Under Win98, they use CRT, with a special set of keyboard map'ngs
for the applications they are using on the Unix side of things, locally
named 'vt221', which allows them to use the upper function keys.
Attached is the output of 'tconv -b vt221' on our Solaris machine
where this map'ng is required, but the output doesn't look anything like
/etc/termcap :(
How can I get the same capabilities into an xterm session for him
as he has through CRT/Win98?
Thanks...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
vt221| Acadia's hybrid of vt100 and vt220,
am, xenl, mir, msgr, xon, cols#80, it#8, lines#24, vt#3,
acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, bel=^G,
cr=\r, csr=^[[%i%p1%d;%p2%dr, tbc=^[[3g, clear=^[[H^[[J, el1=^[[1K,
el=^[[K, ed=^[[J, cup=^[[%i%p1%d;%p2%dH, cud1=\n, home=^[[H,
cub1=\b, cuf1=^[[C, cuu1=^[[A, enacs=^[(B^[)0, smacs=^N,
blink=^[[5m, bold=^[[1m, rev=^[[7m, smso=^[[1;7m, smul=^[[4m,
rmacs=^O, sgr0=^[[m^O, rmso=^[[m, rmul=^[[m, ka1=^[Oq, ka3=^[Os,
kb2=^[Or, kbs=\b, kcbt=^[[Z, kc1=^[Op, kc3=^[On, kdch1=^[[P,
kcud1=^[OB, kent=^[OM, kel=^[[K, kf0=^[Oy, kf1=^[OP, kf10=^[[21~,
kf11=^[[23~, kf12=^[[24~, kf13=^[[25~, kf14=^[[26~, kf15=^[[27~,
kf16=^[[30~, kf17=^[[31~, kf18=^[[32~, kf19=^[[33~, kf2=^[OQ,
kf20=^[[34~, kf21=^[[35~, kf22=^[[36~, kf23=^[[37~, kf24=^[[38~,
kf25=^[[39~, kf26=^[[40~, kf27=^[[41~, kf28=^[[42~, kf3=^[OR,
kf4=^[OS, kf5=^[[16~, kf6=^[[17~, kf7=^[[18~, kf8=^[[19~,
kf9=^[[20~, kfnd=^[[1~, khlp=^[[28~, khome=^[[H, kich1=^[[2~,
kcub1=^[OD, knp=^[[6~, kpp=^[[5~, krdo=^[[29~, kcuf1=^[OC,
kslt=^[[4~, kcuu1=^[OA, rmkx=^[[?1l^[, smkx=^[[?1h^[=,
cud=^[[%p1%dB, cub=^[[%p1%dD, cuf=^[[%p1%dC, cuu=^[[%p1%dA,
rs2=^[^[[?3l^[[?4l^[[?5l^[[?7h^[[?8h, rc=^[8, sc=^[7, ind=\n,
ri=^[M,
sgr=^[[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t^N%e^O%;,
hts=^[H, ht=\t,
Re: Keyboard mappings ...
On Mon, Jul 12, 1999 at 11:50:33AM -0300, The Hermit Hacker wrote: Attached is the output of 'tconv -b vt221' on our Solaris machine where this map'ng is required, but the output doesn't look anything like /etc/termcap :( Try doing infocmp -C vt221 to get termcap output. What you have is terminfo. If you really want to understand terminfo, look at ncurses. -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: bin/12578: `` subshell taints PWD
Hi folks, I'm hoping someone here is interested in tracking down a bug in our /bin/sh . Changing directory within a backtick (``) subshell in sh taints the parent's working directory. The following sample code gives the expected result for /bin/csh, but breaks for /bin/sh cd /tmp echo .`cd /`. pwd Any takers? Ciao, Sheldon. PS: And no, this is not an invitation to chat about the default shell for the base system. :-) PPS: S! PPPS: www.s.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Keyboard mappings ...
Beautiful...thanks :) Infocmp doesn't exist under FreeBSD, but Solaris
has it :)
On Mon, 12 Jul 1999, Dominic Mitchell wrote:
On Mon, Jul 12, 1999 at 11:50:33AM -0300, The Hermit Hacker wrote:
Attached is the output of 'tconv -b vt221' on our Solaris machine
where this map'ng is required, but the output doesn't look anything like
/etc/termcap :(
Try doing infocmp -C vt221 to get termcap output. What you have is
terminfo. If you really want to understand terminfo, look at ncurses.
--
Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator
In Mountain View did Larry Wall
Sedately launch a quiet plea:
That DOS, the ancient system, shall
On boxes pleasureless to all
Run Perl though lack they C.
--
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
**
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: bin/12578: `` subshell taints PWD
Sheldon Hearn wrote:
cd /tmp
echo .`cd /`.
pwd
Any takers?
The patch appended seems to fix this, I'd like someone familiar
with sh to review it though, since this may be symptomatic of
a general problem with command substitution.
PS: And no, this is not an invitation to chat about the default shell
for the base system. :-)
You're hinting it should be /bin/sh for root, right?
Regards,
Niall
*** eval.c~ Mon May 10 16:10:16 1999
--- eval.c Mon Jul 12 18:27:44 1999
***
*** 710,715
--- 710,716
((flags EV_EXIT) == 0 || Tflag))
|| ((flags EV_BACKCMD) != 0
(cmdentry.cmdtype != CMDBUILTIN
+|| cmdentry.u.index == CDCMD
|| cmdentry.u.index == DOTCMD
|| cmdentry.u.index == EVALCMD))) {
jp = makejob(cmd, 1);
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: bin/12578: `` subshell taints PWD
On Mon, 12 Jul 1999 18:37:13 GMT, Niall Smart wrote: The patch appended seems to fix this, I'd like someone familiar with sh to review it though, since this may be symptomatic of a general problem with command substitution. As I understand your patch, you're saying we should fork off a child process when the command in question is cd? This is what I missed when I tried ``echo .`sleep 600`.'' and assumed that the result was proof that we always spawn a subprocess for backtick evaluation. :-( Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 22:34:09 +0200, Mark Murray wrote: As long as the documentation is _clear_ that this is not a front-line security tool, but rather a thing to marginally augment logs with user-supplied info, then I'll buy it. This is why I put forward a motion to move pidentd out of security and into net / sysutils last year. The suggestion wasn't well received, but I still think it'd help. I'd also like for the DESCR file for the port to say: This service offers remote users some identity to report back to the local admin when complaining about abuse / break-ins originating from the local host. This issue is way to religious. As long as folk don't do anything blatantly stupid, and as long as the caveats are well documented, it is probably a good idea to just let this one stand, and lean on it gently :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCCARD and Vpp voltage
In message 378987f5.8d53...@softweyr.com Wes Peters writes: : It shouldn't be all that hard to read the register and set the voltages : appropriately. Table 5-1 on p. 54 has the PC Card register values for : CVS[2:1] and what they mean. Agreed... : Quatech or Socket Communications? I don't see one right off. Socket. I'm going for the low power ruggedized one, unless I can find something better to use. But that's for my PDA so I can NFS mount a root file system after the kernel has booted. I wish I had more CF slots on this beast Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
keymapping continued ...
Morning...
Got a couple of suggestions, and have tried both, with the
xkeycaps appearing to be the more practical for what I'm trying to get
done, I think.
From reading the xkeycaps man page, its a frontend for xmodmap,
but reading *its* man page pretty much got me nowhere fast, so I'm going
to try again with an example, as it might be that I'm just missing
something...
I need to build a keyboard map such that:
F1 == ESC OP
F2 == ESC OQ
Shift-F1 == ESC [31~
Shift-F2 == ESC [32~
Now, in xkeycaps, it allows me to remap keys but gives you a
fixed list of what it wants.
Now, looking at the output of the infocmp command someone
previously suggested for going from terminfo-termcap, I can see the
sequences:
k1=\EOP
Which says that F1 sends out \EOP (ESC OP)
Now, if I add the vt221 entry generated by infocmp, do a 'set
term' and telnet over to the remote host where I need to run the app, and
do a 'set term' over there, and hit 'F1', it generates ESC [11~ instead of
the ESC OP that I'm trying to tell it to send...
So, I'm guessing that I have to do an 'xmodmap' vs a termcap
entry?
If so, how would I build up the above? I need to do F1-F12 +
Shift_F1-Shift_F12 for this to be feasible.
If I have to install some sort of 'terminal package' for him to be
able to do this, this is acceptable, we just need to get the map'ngs
themselves working...
Hopefully this makes a bit more sense?
Thanks...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: keymapping continued ...
On Mon, 12 Jul 1999 15:04:43 -0300, The Hermit Hacker wrote: Hopefully this makes a bit more sense? What doesn't make sense is the fact that a FreeBSD developer, who should know better, is mailing this sort of thing to freebsd-hackers. Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
In message 1336.931774...@zippy.cdrom.com Jordan K. Hubbard writes: : Paging Terry Lambert, Terry Lambert - do you read me? It's time for : your annual rant on the topic of memory overcommit. :-) I thought it was time for his annual rant about how the current FreeBSD development model is going to have problems scaling... :-) Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: keymapping continued ...
In message pine.bsf.4.05.9907121449570.66634-100...@thelab.hub.org The Hermit Hacker writes: : I need to build a keyboard map such that: : : F1 == ESC OP : F2 == ESC OQ : Shift-F1 == ESC [31~ : Shift-F2 == ESC [32~ Why not do this with Xterm translations? Generally speaking xmodmap and friends are poor choices to even think about doing this with since they don't translate function keys to escape sequences. The applications do that, if they want. The only time you're likely to need them is in a terminal emulation situation, which makes xterm the logical place to do this. : Hopefully this makes a bit more sense? Yes. It does. You should use the translations resource for XTerm to accomplish this. From my .Xdefaults file: XTerm*vt100*translations: #override \n\ Alt KeyPress y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\ Meta KeyPress y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\ KeyPress BackSpace: string( 0x7f )\n is one example. It allows me to map the BackSpace key into a DEL character (which in my religion is the right thing to do, your religion might vary), as well as giving me an easy way to paste, at least into xterms when I don't have a middle mouse button. This could easily be expanded to include all the vt220 keys that your boss/coworker needs in xterm. Check out the xterm man page for a more complete example, including ways of mapping different keymaps at the touch of a key. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: keymapping continued ...
On Mon, 12 Jul 1999, Sheldon Hearn wrote:
On Mon, 12 Jul 1999 15:04:43 -0300, The Hermit Hacker wrote:
Hopefully this makes a bit more sense?
What doesn't make sense is the fact that a FreeBSD developer, who should
know better, is mailing this sort of thing to freebsd-hackers.
You know what I always love? someone telling another they posted to the
wrong place without taking the second to tell them a better place to post
it...almost as bad as posting to the wrong place in the first place, and
more of a waste of bandwidth...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: keymapping continued ...
Perfect, slowly putting it together. One thing that I didn't find in the
man page, and am wondering if its just somethign I did wrong, but does
ordering matter?
I put in, first time through:
KeyPress F1: ...
Shift KeyPress F1: ...
And it Shift-F1 and F1 both gave the same answers...
But, if I reverse it, it works as expected/hoped...
Mistake on my part, or normal?
thanks...
On Mon, 12 Jul 1999, Warner Losh wrote:
In message pine.bsf.4.05.9907121449570.66634-100...@thelab.hub.org
The Hermit Hacker writes:
: I need to build a keyboard map such that:
:
: F1 == ESC OP
: F2 == ESC OQ
: Shift-F1 == ESC [31~
: Shift-F2 == ESC [32~
Why not do this with Xterm translations? Generally speaking xmodmap
and friends are poor choices to even think about doing this with since
they don't translate function keys to escape sequences. The
applications do that, if they want. The only time you're likely to
need them is in a terminal emulation situation, which makes xterm the
logical place to do this.
: Hopefully this makes a bit more sense?
Yes. It does. You should use the translations resource for XTerm to
accomplish this. From my .Xdefaults file:
XTerm*vt100*translations: #override \n\
Alt KeyPress y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\
Meta KeyPress y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\
KeyPress BackSpace: string( 0x7f )\n
is one example. It allows me to map the BackSpace key into a DEL
character (which in my religion is the right thing to do, your
religion might vary), as well as giving me an easy way to paste, at
least into xterms when I don't have a middle mouse button.
This could easily be expanded to include all the vt220 keys that your
boss/coworker needs in xterm.
Check out the xterm man page for a more complete example, including
ways of mapping different keymaps at the touch of a key.
Warner
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Mon, 12 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. This seems like a very Linuxy development trend. It's the way the Bazaar works, but not in a Cathedral. Rather, you have a look at what's already there and try to work on it. You don't start your own wing a few feet from the Cathedral in the hopes that someone will bash down a similar wing elsewhere and join yours to the main building. It's out with the bad, in with the good. Pidentd code is pretty terrible. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. But frankly, I highly doubt anyone will find anything to exploit. And, why would bugtraq advisories against other identds apply to my ident_stream service? This is an entirely different code base. Waffle waffle. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: keymapping continued ...
Okay, slowly getting somewhere, I think...
We setup the .Xdefaults file, as follows, on the remote server and are
starting an xterm to the client machine, which is acceptable, but I must
be missing something:
XTerm*vt100*translations: #override \n\
Shift KeyPress F1:string(0x1B) string(0x5B) string(0x33) string(0x33)
string(0x7E)\n\
KeyPress F1:string(0x1B) string(0x4F) string(0x50)\n\
Shift KeyPress F5:string(0x1B) string(0x5B) string(0x33) string(0x35)
string(0x7E)\n\
KeyPress F5:string(0x1B) string(0x5B) string(0x31) string(0x36)
string(0x7E)\n
Now, when I press 'Shift F5', I get [35~ showing up on the app, but its as if
the ESC didn't go through...
Is there a better way I should be writing this? I'm going by the example it
showed for sending multiple characters, but there might be another function
I should be using for this?
The neat thing is that the F5 one worked fine, its only the 'Shift F5' one so
far that isn't...
Thanks...
On Mon, 12 Jul 1999, The Hermit Hacker wrote:
Perfect, slowly putting it together. One thing that I didn't find in the
man page, and am wondering if its just somethign I did wrong, but does
ordering matter?
I put in, first time through:
KeyPress F1: ...
Shift KeyPress F1: ...
And it Shift-F1 and F1 both gave the same answers...
But, if I reverse it, it works as expected/hoped...
Mistake on my part, or normal?
thanks...
On Mon, 12 Jul 1999, Warner Losh wrote:
In message pine.bsf.4.05.9907121449570.66634-100...@thelab.hub.org
The Hermit Hacker writes:
: I need to build a keyboard map such that:
:
: F1 == ESC OP
: F2 == ESC OQ
: Shift-F1 == ESC [31~
: Shift-F2 == ESC [32~
Why not do this with Xterm translations? Generally speaking xmodmap
and friends are poor choices to even think about doing this with since
they don't translate function keys to escape sequences. The
applications do that, if they want. The only time you're likely to
need them is in a terminal emulation situation, which makes xterm the
logical place to do this.
: Hopefully this makes a bit more sense?
Yes. It does. You should use the translations resource for XTerm to
accomplish this. From my .Xdefaults file:
XTerm*vt100*translations: #override \n\
Alt KeyPress y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\
Meta KeyPress y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\
KeyPress BackSpace: string( 0x7f )\n
is one example. It allows me to map the BackSpace key into a DEL
character (which in my religion is the right thing to do, your
religion might vary), as well as giving me an easy way to paste, at
least into xterms when I don't have a middle mouse button.
This could easily be expanded to include all the vt220 keys that your
boss/coworker needs in xterm.
Check out the xterm man page for a more complete example, including
ways of mapping different keymaps at the touch of a key.
Warner
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary:
scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: (forw)
On Mon, 12 Jul 1999, Karl Pielorz wrote: Mark Newton wrote: Karl Pielorz wrote: Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? Garbage. You can do this on any OS, whether it supports loadable modules or not, if you've managed to win sufficient privileges through some other means. I was actually leaning towards that... My boss had kittens here (we have 12 FreeBSD boxes running the show now), until I'd explained it to him... If syscall's need to be replaced, they need to be replaced - and if they are replaceable ... (I'll stop there) :) The article (from what I can remember) didn't actually go out of it's way to say you have to have be root to load the modules in the first place :) - Maybe it's warrants some kind of response page putting up somewhere? - this is also getting off topic for -hackers :(... It was mentioned when describing the conditions for allowing the file load (securelevel == 0 uid == 0). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: (forw)
I would suggest that a version of this document be incorporated into our docs. It's not like it says anythign new, but it's a really good introduction to KLD modules and maybe it's be better to have those documents around to remind people how easy it is to hack a system once root is broken. julian On Mon, 12 Jul 1999, Karl Pielorz wrote: Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? -Kp crypt0genic wrote: Have you all seen this? From: Anonymous nob...@replay.com To: bugt...@securityfocus.com Hi folks, THC released a new article dealing with FreeBSD 3.x Kernel modules that can attack/backdoor the system. You can find our article on http://thc.pimmel.com or http://r3wt.base.org. Greets, pragmatic / The Hacker's Choice To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: more amd hangs
On Fri, 9 Jul 1999, Doug wrote:
In my continuing efforts to get this freebsd box into shape for
web hosting at my company (where it relies exclusively on NFS for
retrieving customer data) I've been making progress thanks to some recent
commits by Peter. Now I can run the heavy duty NFS access script and it
completes its mission about 2 out of 3 times. Also, now when it fails it
doesn't lock the whole box, just amd. Still not where I want it to be, but
it is definitely big progress. :)
What happens when it hangs is that amd becomes totally wedged. I
cannot do 'df' or 'ls /' at all (the amd mountpoints are on /), and
killing the amd process is no help; I have to reboot the box. Ktrace'ing
amd at this point gets me nothing. The ktrace process just dies and leaves
a 0 byte ktrace.out file. (BTW, I am also still having problems with
ktrace exiting while the process is still running when I actually get it
to attach, if anyone cares.)
Still working on this problem. Thanks to some suggestions I got
off the list, I have compiled libc and amd with debugging symbols. I
wedged the box the same way I have previously, by running a perl script
that automounts a directory, reads 250 files in that directory, automounts
another one, etc. for a total of 68 directories.
Using today's current this time amd wedged in the following state
according to top:
155 root3 0 736K 520K siobi 1 0:21 0.00% 0.00% amd
Here is the trace after killing it:
Core was generated by `amd'.
Program terminated with signal 3, Quit.
#0 0x8063dc4 in open ()
(gdb) where
#0 0x8063dc4 in open ()
#1 0x806b5c3 in vsyslog (pri=6, fmt=0x809279a %s, ap=0xbfbfd2c0 )
at /usr/src/lib/libc/../libc/gen/syslog.c:262
#2 0x806b2c2 in syslog (pri=6, fmt=0x809279a %s)
at /usr/src/lib/libc/../libc/gen/syslog.c:130
#3 0x805a3d8 in real_plog (lvl=6,
fmt=0x8091440 prime_nfs_fhandle_cache: NFS version %d,
vargs=0xbfbfdafc \002)
at
/usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:443
#4 0x805a2be in plog (lvl=16,
fmt=0x8091440 prime_nfs_fhandle_cache: NFS version %d)
at
/usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:383
#5 0x805323a in prime_nfs_fhandle_cache (path=0x80cb287
/Space/209.132.66,
fs=0x80b5640, fhbuf=0xbfbfdb34, wchan=0x80b57c0)
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/ops_nfs.c:262
#6 0x805363f in nfs_init (mf=0x80b57c0)
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/ops_nfs.c:542
#7 0x804a7f9 in amfs_auto_bgmount (cp=0x80c8600, mpe=0)
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amfs_auto.c:676
#8 0x804a4bc in amfs_auto_retry (rc=0, term=0, closure=0x80c8600)
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amfs_auto.c:402
#9 0x8055212 in do_task_notify ()
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/sched.c:239
#10 0x804df6d in softclock ()
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:212
#11 0x8052583 in run_rpc ()
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:253
#12 0x80527e6 in mount_automounter (ppid=154)
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:467
#13 0x804a109 in main (argc=4, argv=0xbfbfddec)
at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amd.c:544
#14 0x80480e9 in _start ()
I'm going to work on attaching it with gdb while it's locked next.
Also based on advice I've made some changes to my configuration
files, although it didn't help the 'ls /' or 'df' problems.
Thanks for any help,
Doug
--
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers
[ global ]
# Only search for maps of this type
map_type = file
# Search this path for maps
search_path =/etc
# Use this directory for amd's private mount points
auto_dir = /usr/amd/realmounts
# Log all activity to syslog (daemon)
log_file = syslog:local7
log_options =all
# Check /etc/hosts for hostnames
normalize_hostnames = yes
# Lock the amd process into memory, improves perf.
plock = yes
# Use the special /default entry in maps
selectors_on_default = yes
# DEFINE AN AMD MOUNT POINT
[ /usr/amd/Interfaces ]
map_name = amd.Interfaces
[ /usr/amd/Hold ]
map_name = amd.Hold
32# more /etc/amd.Interfaces
/defaults type:=nfs;opts:=rw,vers=2,intr,proto=udp,noconn
209.132.4 netapp01:/vol/Space/209.132.4
* rhost:=IP${key};rfs:=/Space/${key}
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: (forw)
On Mon, 12 Jul 1999, Doug Rabson wrote: On Mon, 12 Jul 1999, Karl Pielorz wrote: Mark Newton wrote: Karl Pielorz wrote: Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? Garbage. You can do this on any OS, whether it supports loadable modules or not, if you've managed to win sufficient privileges through some other means. I was actually leaning towards that... My boss had kittens here (we have 12 FreeBSD boxes running the show now), until I'd explained it to him... If syscall's need to be replaced, they need to be replaced - and if they are replaceable ... (I'll stop there) :) The article (from what I can remember) didn't actually go out of it's way to say you have to have be root to load the modules in the first place :) - Maybe it's warrants some kind of response page putting up somewhere? - this is also getting off topic for -hackers :(... It was mentioned when describing the conditions for allowing the file load (securelevel == 0 uid == 0). which suggests that most important servers should be run whith securelevel 0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
Whatever you do with identd, just make it work through NAT. That's the #1 request from folks where this is concerned. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: hardware
On Fri, 9 Jul 1999, Jake Burkholder wrote: Nvidia cards are already supported. The GL xlock savers look awesome. Really? Wow. The xscreensaver GL savers looked like crap, the xlockmore ones worked for about oh two seconds, before slowing down to unaccelerated speeds. This at 640x480x16 too. Hmm. At least 2D works great at 1152x864x32. - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCCARD and Vpp voltage
Warner Losh wrote: In message 378987f5.8d53...@softweyr.com Wes Peters writes: : It shouldn't be all that hard to read the register and set the voltages : appropriately. Table 5-1 on p. 54 has the PC Card register values for : CVS[2:1] and what they mean. Agreed... : Quatech or Socket Communications? I don't see one right off. Socket. I'm going for the low power ruggedized one, unless I can find something better to use. But that's for my PDA so I can NFS mount a root file system after the kernel has booted. I wish I had more CF slots on this beast Time to build a CF expansion cage? Or, better yet, a CF to PCCard cage? ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: more amd hangs
Ok, it's now wedged in a different state (using the same perl script to wedge it). According to top: 317 root2 0 648K 456K STOP 0 0:00 0.00% 0.00% amd I also managed to attach to the running process this time: (gdb) file /usr/sbin/amd Reading symbols from /usr/sbin/amd...done. (gdb) attach 317 Attaching to program: /usr/sbin/amd, process 317 0x8063c34 in select () (gdb) where #0 0x8063c34 in select () #1 0x80523b6 in do_select (smask=0, fds=1024, fdp=0xbfbfd990, tvp=0xbfbfd984) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:146 #2 0x80525fd in run_rpc () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:274 #3 0x80527e6 in mount_automounter (ppid=316) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:467 #4 0x804a109 in main (argc=1, argv=0xbfbfdb84) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amd.c:544 #5 0x80480e9 in _start () I am noticing that the last function, _start() is the same as in the last traceback. Anyone with suggestions, I'm open to them. :) I tried doing 'continue' with gdb and it wedged gdb and amd, so I just rebooted. HTH, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: more amd hangs
On 10 Jul 1999 12:56:41 -0400, R. Matthew Emerson wrote: I thought that it was almost never proper to soft-mount rw filesytems. Am I mistaken about this? I must admit, it sounds like sensible advice. The only NFS exports which I have to rely on are read-only mounts. The only time I soft-mounted a read-write export was when I was mucking around with buildworld over NFS, and it didn't cause me problems then. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: more amd hangs: in _start()
Ok, got another hang in siobi state (this time after it successfully completed the script). Here is the trace: (gdb) file /usr/sbin/amd Reading symbols from /usr/sbin/amd...done. (gdb) attach 155 Attaching to program: /usr/sbin/amd, process 155 0x8063dc4 in open () (gdb) where #0 0x8063dc4 in open () #1 0x806b5c3 in vsyslog (pri=6, fmt=0x809279a %s, ap=0xbfbfb240 X) at /usr/src/lib/libc/../libc/gen/syslog.c:262 #2 0x806b2c2 in syslog (pri=6, fmt=0x809279a %s) at /usr/src/lib/libc/../libc/gen/syslog.c:130 #3 0x805a3d8 in real_plog (lvl=6, fmt=0x8091ea0 recompute_portmap: NFS version %d, vargs=0xbfbfba7c \002) at /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:443 #4 0x805a2be in plog (lvl=16, fmt=0x8091ea0 recompute_portmap: NFS version %d) at /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:383 #5 0x80556f8 in recompute_portmap (fs=0x80c9f80) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/srvr_nfs.c:285 #6 0x80559ff in nfs_srvr_port (fs=0x80c9f80, port=0xbfbfbabe, wchan=0x0) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/srvr_nfs.c:564 #7 0x80534cd in call_mountd (fp=0xbfbfdb24, proc=3, f=0, wchan=0x0) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/ops_nfs.c:438 #8 0x8053a3d in nfs_umounted (mp=0x80cad00) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/ops_nfs.c:796 #9 0x804dd4f in am_unmounted (mp=0x80cad00) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/autil.c:366 #10 0x8050b22 in free_map_if_success (rc=0, term=0, closure=0x80cad00) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/map.c:924 #11 0x8055212 in do_task_notify () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/sched.c:239 #12 0x804df6d in softclock () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:212 #13 0x8052583 in run_rpc () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:253 #14 0x80527e6 in mount_automounter (ppid=154) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:467 #15 0x804a109 in main (argc=4, argv=0xbfbfddec) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amd.c:544 #16 0x80480e9 in _start () I'm going to have a go at the code now that I can be fairly certain that _start() is the culprit. (Please everyone, stop laughing, thanks. :) Comments or suggestions welcome. Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Daniel C. Sobral d...@newsguy.com wrote: That's *not* abomination. How about pre-allocating over 100 Mb for X Free, for instance? What about it? If an application does not need 100MB, it should not malloc it. If it does need it, it should malloc it and know that it is available if the malloc succeeds. Basically, if you don't have enough memory, you just don't have enough memory. Yes, and the application should be told this via the standard documented interface for doing so, i.e. returning NULL from malloc(). What FreeBSD does *reduces* the need for memory. If FreeBSD *did not* do it, then you'd need much more memory. Why? Are there really such a lot of applications allocating vastly more memory than they actually use? Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
On Mon, 12 Jul 1999 23:56:29 +0100, Jon Ribbens wrote: What about it? If an application does not need 100MB, it should not malloc it. If it does need it, it should malloc it and know that it is available if the malloc succeeds. You're rehashing stuff that's been discussed to death. Please look at the mailing list archives for this mailing list. If you're not prepared to do that, the long and the short of it is that FreeBSD _does_ overcommit, we like it that way and neither of these two facts is likely to change. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Sheldon Hearn sheld...@uunet.co.za wrote: You're rehashing stuff that's been discussed to death. Please look at the mailing list archives for this mailing list. I'd love to, could you please be more specific? I can't find anything relevant searching for 'malloc' or 'overcommit'. If you're not prepared to do that, the long and the short of it is that FreeBSD _does_ overcommit, we like it that way and neither of these two facts is likely to change. I can add it to the list of reasons I don't use it then I guess ;-). Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
On Tue, 13 Jul 1999 00:20:27 +0100, Jon Ribbens wrote: I'd love to, could you please be more specific? I can't find anything relevant searching for 'malloc' or 'overcommit'. My apologies. It was the current mailing list. Search for malloc AND NULL AND kill, and pick out the swap-related problems thread. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
According to Warner Losh: I thought it was time for his annual rant about how the current FreeBSD development model is going to have problems scaling... No no, I think you're thinking of the write-lock read-lock we should use on CVS in order to have the Hamiltonian graph without cycle to solve dependencies with the fine-grained giant lock on SMP systems. Did I catch all the remaining rants ? :-) Oh I forgot the one about having a veto system for I don't remember what... [ Sorry Terry, couldn't resist, please forgive me :) ] -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #72: Mon Jul 12 08:26:43 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Yuck. That's a complete abomination. What's the point of it? It's turning Paging Terry Lambert, Terry Lambert - do you read me? It's time for your annual rant on the topic of memory overcommit. :-) It's not overcommit so much as it is what happens to a process that gets a page fault when there are no available pages to 'fix up' the overcommit. AIX began overcommitting at one point but would kill -9 any process that page faulted when there were no available pages. AIX sysadmins universally hated this behavior and allocated HUGE swap files to avoid it. I assume FreeBSD does something more reasonable. Todd Whitesel toddpw @ best.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 3.2-STABLE not stable but panicy?
This is typically symptomatic of poor CPU cooling; all of a sudden you are running the CPU at full power 100% of the time, rather than sitting in an HLT instruction. It can be further exacerbated if you're overclocking. Is it just me/my machine or has 3.2-STABLE become rather unstable and panic stricken (sp)? Whether it has any correlation I don't know, but it seems to have started when I got in the the RC5DES project a couple of days ago. Yesterday I got a panic like: (no debugging symbols found)... IdlePTD 3174400 initial pcb at 28e864 panicstr: lockmgr: unknown locktype request 0 panic messages: --- panic: lockmgr: unknown locktype request 0 syncing disks... 160 159 139 113 80 32 done dumping to dev 30401, offset 327680 dump 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc01594ff in boot () (kgdb) bt #0 0xc01594ff in boot () #1 0xc0159784 in at_shutdown () #2 0xc01555c4 in lockmgr () #3 0xc017ba88 in vop_stdlock () #4 0xc01f7e19 in ufs_vnoperate () #5 0xc0184863 in vn_lock () #6 0xc017e40b in vget () #7 0xc017a55b in vfs_cache_lookup () #8 0xc01f7e19 in ufs_vnoperate () #9 0xc017cb45 in lookup () #10 0xc017c618 in namei () #11 0xc0180969 in change_dir () #12 0xc01808c7 in chdir () #13 0xc021cf63 in syscall () #14 0xc0213cec in Xint0x80_syscall () #15 0x804919f in ?? () #16 0x804af96 in ?? () #17 0x804904d in ?? () (kgdb) I decided to cvsup the latest -STABLE sources and with a kernel based on yesterdays -STABLE I just got (again during a RC5DES run, approx 15 minutes after starting it): (no debugging symbols found)... IdlePTD 3239936 initial pcb at 29e914 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3ff02585 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02078b4 stack pointer = 0x10:0xc6a158b4 frame pointer = 0x10:0xc6a158c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 973 (cron) interrupt mask = net tty bio cam trap number = 12 panic: page fault syncing disks... done dumping to dev 30401, offset 327680 dump 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 1 8 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc0159e07 in boot () (kgdb) bt #0 0xc0159e07 in boot () #1 0xc015a08c in at_shutdown () #2 0xc021e089 in trap_fatal () #3 0xc021dd67 in trap_pfault () #4 0xc021da0a in trap () #5 0xc02078b4 in zalloci () #6 0xc021ac12 in get_pv_entry () #7 0xc021ada7 in pmap_insert_entry () #8 0xc021b589 in pmap_enter_quick () #9 0xc021b7aa in pmap_object_init_pt () #10 0xc0149c77 in elf_load_section () #11 0xc014a2ae in exec_elf_imgact () #12 0xc01534ff in execve () #13 0xc021e2cb in syscall () #14 0xc0214ecc in Xint0x80_syscall () Cannot access memory at address 0xbfbfd7d8. (kgdb) Before someone asks: yes, I checked the CPU fan.. dmesg: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-STABLE #0: Sat Jul 10 10:49:28 CEST 1999 wi...@yedi.iaf.nl:/usr/freebsd-3.1-stable-src/src/sys/compile/YEDI Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 261958495 Hz CPU: AMD-K6tm w/ multimedia extensions (261.96-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x562 Stepping = 2 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX AMD Features=0x400b10 real memory = 100663296 (98304K bytes) avail memory = 94621696 (92404K bytes) Preloaded elf kernel kernel at 0xc0305000. Probing for devices on PCI bus 0: chip0: Intel 82439HX PCI cache memory controller rev 0x03 on pci0.0.0 chip1: Intel 82371SB PCI to ISA bridge rev 0x01 on pci0.7.0 xl0: 3Com 3c905-TX Fast Etherlink XL rev 0x00 int a irq 14 on pci0.9.0 xl0: Ethernet address: 00:60:08:09:b8:f1 xl0: autoneg not complete, no carrier (forcing half-duplex, 10Mbps) vga0: Matrox MGA 2164W graphics accelerator rev 0x00 int a irq 14 on pci0.10.0 Qlogic ISP Driver, FreeBSD CAM Version 0.992, Core Version 1.9 isp0: Qlogic ISP 1020/1040 PCI SCSI Adapter rev 0x05 int a irq 9 on pci0.11.0 isp0: set PCI line size to 16 isp0: set PCI latency to 64 isp0: Ultra Mode Capable isp0: Board Revision 1040B, loaded F/W Revision 7.63.0 isp0: Last
Re: Replacement for grep(1) (part 2)
Jon Ribbens wrote: Daniel C. Sobral d...@newsguy.com wrote: That's *not* abomination. How about pre-allocating over 100 Mb for X Free, for instance? What about it? If an application does not need 100MB, it should not malloc it. If it does need it, it should malloc it and know that it is available if the malloc succeeds. Well, learn something about real programs first, and then come back. Basically, if you don't have enough memory, you just don't have enough memory. Yes, and the application should be told this via the standard documented interface for doing so, i.e. returning NULL from malloc(). This results in the applications working with less memory than would actually be possible through overcommit. What FreeBSD does *reduces* the need for memory. If FreeBSD *did not* do it, then you'd need much more memory. Why? Are there really such a lot of applications allocating vastly more memory than they actually use? Right. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Jon Ribbens wrote: If you're not prepared to do that, the long and the short of it is that FreeBSD _does_ overcommit, we like it that way and neither of these two facts is likely to change. I can add it to the list of reasons I don't use it then I guess ;-). Whatever. The operating system you use also does it. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Ollivier Robert wrote: Oh I forgot the one about having a veto system for I don't remember what... Veto based locking for the fs. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. I'm actually more worried about the opposing trend that you espouse, where the seniority of a code entity is considered more significant than its functionality. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Compromising a FreeBSD from inside (was: (forw))
People, how much attention are you going to get to this topic with a subject line like (forw)? On Monday, 12 July 1999 at 12:28:03 +, crypt0genic wrote: Have you all seen this? To: bugt...@securityfocus.com Hi folks, THC released a new article dealing with FreeBSD 3.x Kernel modules that can attack/backdoor the system. You can find our article on http://thc.pimmel.com or http://r3wt.base.org. For those of us who *hate* incorrect or approximate URLs, try http://thc.pimmel.com/files/thc/bsdkern.html. Greets, pragmatic / The Hacker's Choice On Monday, 12 July 1999 at 21:19:45 +0930, Mark Newton wrote: Karl Pielorz wrote: Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? Garbage. You can do this on any OS, whether it supports loadable modules or not, if you've managed to win sufficient privileges through some other means. FreeBSD (and other OSs with loadable module support) merely provides a well-defined API which, like almost every other well- defined API, can be abused by those who harbor ill-will. Making the interface complicated does absolutely nothing to stop script-kiddies: Once a complicated interface is in an exploit script, who cares how arcane it is? In fact, the most interesting thing about this (rather large) document is that it's the best documentation I've seen on klds. I don't know why anybody would want to use it for compromising security, since it's a *lot* of work, and to even get as far as installing it you have to be root already, so you would have plenty of easier alternatives. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Compromising a FreeBSD from inside (was: (forw))
On Tue, 13 Jul 1999, Greg Lehey wrote: In fact, the most interesting thing about this (rather large) document is that it's the best documentation I've seen on klds. I don't know why anybody would want to use it for compromising security, since it's a *lot* of work, and to even get as far as installing it you have to be root already, so you would have plenty of easier alternatives. It's more for hiding yourself once you're already in; if you load a module at boot-time which hides the fact that it was loaded, hides the module itself from being listed by the filesystem syscalls, and hides whatever else you want, you could presumably stay hidden a lot easier. Kris - Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes. -- Unknown To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
On Tue, 13 Jul 1999, Daniel C. Sobral wrote: Jon Ribbens wrote: Daniel C. Sobral d...@newsguy.com wrote: That's *not* abomination. How about pre-allocating over 100 Mb for X Free, for instance? What about it? If an application does not need 100MB, it should not malloc it. If it does need it, it should malloc it and know that it is available if the malloc succeeds. Well, learn something about real programs first, and then come back. Basically, if you don't have enough memory, you just don't have enough memory. Yes, and the application should be told this via the standard documented interface for doing so, i.e. returning NULL from malloc(). This results in the applications working with less memory than would actually be possible through overcommit. What FreeBSD does *reduces* the need for memory. If FreeBSD *did not* do it, then you'd need much more memory. Why? Are there really such a lot of applications allocating vastly more memory than they actually use? Right. You're not really being fair by giving such simple answers, not that it hasn't been discussed TO DEATH already so i understand your indifference. :) I didn't understand the reasoning of over commit until I was pointed out this scenario: (let's use netscape because it is huge) You're browsing with netscape and It hits about 32megs in size, you click on a multimedia object and netscape execs a helper app. at the moment of the fork you have a major overcommit, considering private mappings and allocated memory that is suddenly doubled when under a second later you will exec a program that is only a meg or so. you also have to consider a program wishing to make sparse use of its address space, without overcommit it becomes impossible. if you want to impose limits, use /etc/login.conf, nuff said. -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
