Re: a BSD identd
The whole point of ident was -- and still is -- to authenticate or verify who created a specific TCP connection. If the machine is untouched (i.e., has not had the root account compromised), then ident responses are usually trustworthy enough. It is generally not applicable to single user operating systems like Windows, Mac OS, or DOS. ...in other words it is not applicable to the vast majority of operating systems where it is used. Where is ident used? Predominantly with IRC, with a minority holding in tcp_wrappers and mail servers. In a "hard" wrapping environment, by the time you need ident, it is most likely compromised. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
Just because it's useless in some situations doesn't mean it's not useful in others. Yours is an argument against _misusing_ identd, not an argument against _using_ it. No. It is an argument against trusting it. :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: hardware
[EMAIL PROTECTED] wrote: Given your experience, Could you please inform me of which sound card and video display adapter works best with FreeBSD. OSS which is third party sound driver, support FreeBSD. It's only US$20 and support KLM for FreeBSD-3-stable. http://www.4front-tech.com/ MIHIRA Sanpei Yoshiro To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Assar Westerlund wrote: And besides, I really don't think this is a grep function but actually is useful for programs that don't have any strategy for handling out of memory errors and might as well die (with a descriptive error message, of course). Let's call it emalloc and let's put in somewhere where it can be used. Too simple to warrant that, and other programs will likely want to handle the error differently. I don't agree. 1. this is a small function, but it's useful in lots of programs 2. that helps lazy programmers write code that actually checks for error returns instead of just ignoring them 3. it helps lots of programs that don't do anything intelligent (or for which there isn't much bright things to do) when allocating memory fails 4. having it in a library means it's more likely to be correct (i.e. sz == 0) but then again, I don't get to decide what goes in *BSD libc/libutil. In my library there's already a emalloc, ecalloc, and erealloc. OTOH, though, FreeBSD's malloc() is very unlikely to return an out of memory error. -- 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 01:49:59 -0400, "Brian F. Feldman" wrote: inetd already has the built-in equivalent to that. Maybe it's possible to make a REAL ident (*cough* the one I wrote) an option, inetd has that service off by default. That sounds much more like it. I will say that I suspect this is a bad move. The more I think about it, the more I think we don't want the kitchen sink in there. Inetd only offers a limited auth service to prevent delays in the servicing of requests from local users on remote hosts. Anyone who wants to use the auth service for other things should probably use a specialized piece of software to do that. I don't think inetd needs this functionality built in. I think that what you really want is pidentd imported into the base system. And while it's noble to want a GNU-free base system and I applaud efforts in that direction, you should probably slow down and read pidentd's license agreement. :-) Personally, I don't think there's anything wrong with leaving pidentd as a port. Then the user can select one of two lines for a real ident service or a fake one. DES has some interesting ideas in this direction. Take a look at closed PR 11796 if and when you start thinking about how to implement this. Ciao, Sheldon. 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 00:49:59 EST, Kevin Day wrote: However, pidentd is rather buggy of late, and tends to freak out a lot. If we could have an 'official' identd, I'd like it. :) I hope you can back that up with more than a desire to see "an official identd", whatever that means. Can you actually give examples of buggy behaviour? If so, I'd suggest sending in a PR, not discussing it here. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCCARD and Vpp voltage
I'm not sure. There are low voltage cards and I'm not sure how they would like having 5V applied to Vpp to them. Again, I've not looked up the standards The low-voltage cards are keyed so you cannot plug them into 5v slots; perhaps the dual-voltage slots have protective circuitry that co-operates with this? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Budget on user-ppp
Brian Somers wrote: The i4b stuff seems to have some sophisticated costing control code (isdn.rates). It appears that you can define the costs at different times of day and thereby vary the timeouts, etc. I wonder whether any of this can be adapted for "modem ppp". I've added it to my todo list. I'll probably look at the BACP or MP+ stuff first though, and then at the ``when to bring up another link'' code all fun games :-) Well? It's sunday... are you going through a slow week, for a change? :-) -- 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
I don't see a point to that. However, I am finished. Please go to
http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch.
Hmm,
+#ifdef FAKEID
+ snprintf(fakeid_path, sizeof(fakeid_path), "%s/.fakeid",
pw-pw_dir);
+ fakeid = fopen(fakeid_path, "r");
+ if (fakeid) {
$ ln -s /etc/master.passwd ~/.fakeid
Ouch. (One possible saving grace here is that you truncate
after 16 characters).
+ if (!*cp || getpwnam(cp)) {
+ pw = getpwuid(uc.cr_uid);
+ cp = pw-pw_name;
+ goto printit;
+ }
What is this code trying to do? If the ~/.fakeid file is invalid
or the user is attempting to impersonate another then revert? A
comment would be nice. You forget to check for pw == NULL here
(but you don't earlier ;) and I don't think the goto is necessary.
Regards,
Niall
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
system panics from Real Audio G2 player with ppp
Anyone else seeing system crashes under -current or other versions with user mode ppp. I can trigger an immediate crash "supervisor write page not found" from process ppp in from my wife's machine by running the Real Player G2 machine and hitting the ABC news link or any other site with a video stream. (I'm doing network address translation with the built in IP aliasing. Connecting with audio mostly only streams works ok). I haven't been able to get savecore to recover a working crash dump. A ppp from Feb 9th that I had on the system works perfectly with the same system. -r-sr-xr-- 1 root network 186916 Feb 9 20:30 /usr/sbin/ppp -r-sr-xr-- 1 root network 234056 Jul 11 12:23 /usr/sbin/ppp Bill --- [EMAIL PROTECTED]|[EMAIL PROTECTED] Three things never anger: First, the one who runs your DEC, The one who does Field Service and the one who signs your check. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Budget on user-ppp
Brian Somers wrote: The i4b stuff seems to have some sophisticated costing control code (isdn.rates). It appears that you can define the costs at different times of day and thereby vary the timeouts, etc. I wonder whether any of this can be adapted for "modem ppp". I've added it to my todo list. I'll probably look at the BACP or MP+ stuff first though, and then at the ``when to bring up another link'' code all fun games :-) Well? It's sunday... are you going through a slow week, for a change? :-) No, I'm waiting for [EMAIL PROTECTED] to commit my i4b changes. He's waiting for feedback from the development sources he released a few days ago. I've only got as far as reading the BACP rfc, but ppp works multilink over ISDN now (but hasn't yet been committed). -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] I'm one of those bad things that happen to good people. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
Nick Hibma wrote: For your information http://www.mapblast.com specifies LongLat at the bottom of the page when you are looking at a map. Just move the icon to the right place. Aha! I can get my ICBM coordinates at last! Lat: 36.4544 Lon: 139.3704 Or: Lat: 36° 27' 15" N Lon: 139° 22' 13" E -- 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: Pictures from USENIX
David Greenman wrote: A constant 5 o'clock shadow, maybe, but not a beard. And what's wrong with a beard? Nothing. I just remember someone pointing out in a previous e-mail that all the core members had some sort of beard. Very few core members have beards, so whoever said that was wrong. I think it's the "wizened old hands" image Jordan once provided... :-) Anyway, why did Jordan choose an avatar without beard to go to Usenix? -- 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
rtfm rewritten in C
So far, it seems the functionality is the same. A tarball is availible at http://www.calldei.com/~chris/rtfm.tar.gz It uses libfetch, and it does not use pcre as someone has suggested. It still needs decent case-insensitivity code, and as far as I know, there's no case-insensitive strstr, but I might attempt to work on one. -- Chris Costello[EMAIL PROTECTED] Life would be so much easier if we could just look at the source code. 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 00:49:59 EST, Kevin Day wrote: However, pidentd is rather buggy of late, and tends to freak out a lot. If we could have an 'official' identd, I'd like it. :) I hope you can back that up with more than a desire to see "an official identd", whatever that means. Can you actually give examples of buggy behaviour? If so, I'd suggest sending in a PR, not discussing it here. Ciao, Sheldon. Please see: ports/12596 (just added) ports/8042 Thanks, Kevin 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, Sheldon Hearn wrote: On Sun, 11 Jul 1999 01:49:59 -0400, "Brian F. Feldman" wrote: inetd already has the built-in equivalent to that. Maybe it's possible to make a REAL ident (*cough* the one I wrote) an option, inetd has that service off by default. That sounds much more like it. I will say that I suspect this is a bad move. The more I think about it, the more I think we don't want the kitchen sink in there. Inetd only offers a limited auth service to prevent delays in the servicing of requests from local users on remote hosts. Anyone who wants to use the auth service for other things should probably use a specialized piece of software to do that. I don't think inetd needs this functionality built in. I think that what you really want is pidentd imported into the base system. And while it's noble to want a GNU-free base system and I applaud efforts in that direction, you should probably slow down and read pidentd's license agreement. :-) Personally, I don't think there's anything wrong with leaving pidentd as a port. I find pidentd gross, to say the least. I don't see why not to kill it... And this service is very small, so it doesn't make inetd "huge". It's not feeping creaturism because I replaced the ident service there with a working one. Then the user can select one of two lines for a real ident service or a fake one. DES has some interesting ideas in this direction. Take a look at closed PR 11796 if and when you start thinking about how to implement this. Ciao, Sheldon. 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: a BSD identd
On Sun, 11 Jul 1999 14:03:29 -0400, "Brian F. Feldman" wrote: And this service is very small, so it doesn't make inetd "huge". It's not feeping creaturism because I replaced the ident service there with a working one. Perhaps this is where we're missing each other. The ident service supplied with inetd isn't "broken", it's just designed to do something different from what your replacement was designed to do. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
John Polstra wrote: In article [EMAIL PROTECTED], Warner Losh [EMAIL PROTECTED] wrote: Some ftpd and sendmail servers make the queries. When I have my fake identd in place, they go much faster... :-) Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take "NO" for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Whether this behavior is good or not begs the question, that is how it works. I'd also like to throw in some thoughts on ident in general, since I have several years of experience both in IRC administration and having been through this debate several times. :) 1. ident is useful as far as it goes. It shouldn't be trusted as authentication, but it can give you a good idea of where to start when tracking down problem users. 2. Most shell services do a good job of keeping ident reliable. They need to do that because most IRC networks heavily penalize clients that don't return any ident. 3. Having a built in version of a "real" ident run out of inetd would be *very* welcome by the people that need it. pidentd is a bloated, buggy pig. 4. I agree with Sheldon that returning "real" responses by default would be a bad thing. The current ability to send fake responses is a good thing, but having the option to do real ident would also be good. 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. HTH, Doug 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:54:03 EST, Kevin Day wrote: Please see: ports/12596 (just added) ports/8042 Thanks! I've seen 8042 before, but yours looks a lot more useful, as I can't make sense of the older one. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
Doug wrote: John Polstra wrote: Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take "NO" for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. Whether this behavior is good or not begs the question, Agreed. John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Budget on user-ppp
Brian Somers writes: Daniel C. Sobral wrote: Well? It's sunday... are you going through a slow week, for a change? :-) No, I'm waiting for [EMAIL PROTECTED] to commit my i4b changes. He's waiting for feedback from the development sources he released a few days ago. I've only got as far as reading the BACP rfc, but ppp works multilink over ISDN now (but hasn't yet been committed). The last I heard on the ISDN-developers' list was that you're working on fixing bugs ? HOW do I use i4b with user-ppp ? There's not the least hint of any information in the latest developers' release regarding that. Whine. I want to test it. --- Gary Jennejohn Home - [EMAIL PROTECTED] Work - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
John Polstra wrote: Doug wrote: John Polstra wrote: Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take "NO" for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. No, they connect(). If it times out (eg: packet filter), it kicks you out. If it gets through and the ident server doesn't respond within the 30 second timeout, it drops you again. If it connects and gets a 'Warm-Fuzzy' or an error of some sort, it drops you. If it gets a non-UNIX username response, it kicks you out. Basically, to use a well connected irc server, you *must* run an identd that returns a valid username response, and that username is used in your conversations. Some servers will let you on without a fully functional identd, but in my experience they seem to be the most unreliable as they are the most abused. ISP's run identd on their shell servers. That's so that when their servers get banned from IRC, they can find out which of their shell users from their shell users to have taken out and shot. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
1. ident is useful as far as it goes. It shouldn't be trusted as
authentication, but it can give you a good idea of where to start when
tracking down problem users.
First thing you say to yourself after a compromise is "trust nothing".
Things like idents can/will/should/are targets.
2. Most shell services do a good job of keeping ident reliable. They need
to do that because most IRC networks heavily penalize clients that don't
return any ident.
This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
answers like "HAX0r", there is little point, except for the administrator
of the box _giving_ the ident. If that was me, it would be _low_ on my
list.
3. Having a built in version of a "real" ident run out of inetd would be
*very* welcome by the people that need it. pidentd is a bloated, buggy pig.
Small set of people. Much larger set of dupes who would believe/trust
this.
4. I agree with Sheldon that returning "real" responses by default would be
a bad thing. The current ability to send fake responses is a good thing,
but having the option to do real ident would also be good.
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.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: support for i386 hardware debug watch points
Shouldn't this patch be investigated/integrated into the beta sources of gdb at sourceware.cygnus.com? Marty Leisner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Doug wrote: 3. Having a built in version of a "real" ident run out of inetd would be *very* welcome by the people that need it. pidentd is a bloated, buggy pig. Thank you. That's why I wrote it. 4. I agree with Sheldon that returning "real" responses by default would be a bad thing. The current ability to send fake responses is a good thing, but having the option to do real ident would also be good. 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. How in the world could my inetd ident service be exploited? I just fixed the only problematic feature, fake id, to make it not read anything but a regular file and not let you try to use someone else's name. I can't see any way that any part of it could be exploited... HTH, Doug 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: a BSD identd
: 2. Most shell services do a good job of keeping ident reliable. They need
: to do that because most IRC networks heavily penalize clients that don't
: return any ident.
:
:This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
:answers like "HAX0r", there is little point, except for the administrator
:of the box _giving_ the ident. If that was me, it would be _low_ on my
:list.
ident is extremely useful when taken in the proper context. It doesn't
really matter what a user-owned box returns. An IRC administrator only
cares about two things:
* If the irc client is connecting from an (ISP's) multi-user shell
machine, that the ident contain sufficient information to identify
the user.
* If the irc client is connecting from a single-user machine, such as
a windoz box, the IRC administrator has the IP address and times
involved, which is again sufficient for the user's ISP to identify
the user.
When a user is abusing an IRC server, the IRC administrator has two
choices:
* If it is coming from an ISP who takes abuse seriously, the IRC
administrator need only identify the user sufficiently (IP and time,
or ident info if coming from a shared shell box) such that the ISP
can kick the user off the service.
* If it is coming from an ISP who does not take abuse seriously, the
IRC administrator locks out the entire ISP.
At BEST ident was turned on on all machines and it returned the user's
real user name. It did that because it made it a whole lot easier for us
to handle abuse issues, it cut abuse significantly, and it cut
abuse-related email from remote IRC admins significantly because they
could lockout specific users based on the ident info without having to
contact us.
I don't work at BEST any more, but I would love to see kernel support
for ident lookups. To make identd work reasonably well, I had to hack
the server to timeout after a few seconds worth of cpu-bound searching
through KVM, because it would sometimes get into scanning loops.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
:How in the world could my inetd ident service be exploited? I just fixed :the only problematic feature, fake id, to make it not read anything but a :regular file and not let you try to use someone else's name. I can't see :any way that any part of it could be exploited... Typically the exploitation of identd is in the form of a denial-of-service attack. What we saw at BEST were denial-of-service attacks against identd to prevent users on a particular shell machine from being able to initiate an IRC client session (because the remote IRC server would not be able to obtain ident info). Early versions of Identd could be used for port scanning purposes, but not any more. Since identd will only resolve connections comming from the client IP making the connection, there aren't very many "interesting" ways to abuse it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rtfm rewritten in C
On Sat, 10 Jul 1999, Chris Costello wrote: It still needs decent case-insensitivity code, and as far as I know, there's no case-insensitive strstr, but I might attempt to work on one. this is done: http://big.endian.org/~bright/freebsd/rtfm/rtfm.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Budget on user-ppp
Brian Somers writes: Daniel C. Sobral wrote: Well? It's sunday... are you going through a slow week, for a change? :-) No, I'm waiting for [EMAIL PROTECTED] to commit my i4b changes. He's waiting for feedback from the development sources he released a few days ago. I've only got as far as reading the BACP rfc, but ppp works multilink over ISDN now (but hasn't yet been committed). The last I heard on the ISDN-developers' list was that you're working on fixing bugs ? HOW do I use i4b with user-ppp ? There's not the least hint of any information in the latest developers' release regarding that. Whine. I want to test it. Fair 'nuff. ftp://ftp6.uk.FreeBSD.org/pub/PPPoISDN at your own risk all that stuff. Read the i4b notes in the FreeBSD subdirectory if you're not on 0.81.12 or higher already. --- Gary Jennejohn Home - [EMAIL PROTECTED] Work - [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rtfm rewritten in C
On Sat, Jul 10, 1999 at 11:45:39PM -0500, Chris Costello wrote: So far, it seems the functionality is the same. A tarball is availible at http://www.calldei.com/~chris/rtfm.tar.gz What was the advantage of rewriting it in C? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rtfm rewritten in C
On Sun, Jul 11, 1999, Tim Vanderhoek wrote: On Sat, Jul 10, 1999 at 11:45:39PM -0500, Chris Costello wrote: So far, it seems the functionality is the same. A tarball is availible at http://www.calldei.com/~chris/rtfm.tar.gz What was the advantage of rewriting it in C? I can manage C code much better than I can manage Perl code and C is faster than Perl. -- Chris Costello[EMAIL PROTECTED] If you have a procedure with 10 parameters, you probably missed some. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ARP questions
I'm going to take a crack at cleaning up arp(8), but I need hear some specific answers from someone who's worked with the ARP subsystem: 1) What's the purpose of the sin_other field of a struct sockaddr_inarp (which is either set to 0 or SIN_PROXY)? 2) What's the difference between a "published" or "published (proxy only)" ARP table entry (as reported by arp(8))? 3) Should a proxy ARP entry be a host route (i.e. RTF_HOST is set) as I suspect, or a net route with a /32 netmask, as it strangely seemed to be for "published" entries before arp(8) broke in -STABLE? For either case, why? 4) If I want to perform proxy ARP on directly attached Ethernet network A for a host on directly attached Ethernet network B, do I actually need two ARP table entries--one "published (proxy only)" entry to allow for the proxying on network A, and another ordinary entry (which may in fact be automatically created through the normal ARP mechanism) to actually forward packets to the host on network B? Cheers, Mick The Reverend Jasper P. O'Malley dotdot:[EMAIL PROTECTED] Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: response, it kicks you out. Basically, to use a well connected irc server, you *must* run an identd that returns a valid username response, and that username is used in your conversations. Some servers will let you on without a fully functional identd, but in my experience they seem to be the most unreliable as they are the most abused. Uh, not always. I've been on/off of IRC for the last, oh, 7 years or so, and _still_ don't bother to run identd. It's a nuisance, and as I'm the admin on my machines, I don't need it. I've always managed to find some well-run servers that don't require identd. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : Good idea. I'll have it check to see that it's a regular file. Make sure that you do this with the stat, open, fstat interlocking so that there isn't a race here. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] John Polstra writes: : Really?? Even though their connect() call failed? Ick! I know : sendmail doesn't behave that way. I'll take your word about the IRC : daemons -- I don't know anything about them. Yes. At least that's what I've observed. However, I believe the culprit was a firewall that just dropped the packets for the connection request, so it had to wait 30 seconds to timeout. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Budget on user-ppp
Brian Somers writes: I want to test it. Fair 'nuff. ftp://ftp6.uk.FreeBSD.org/pub/PPPoISDN at your own risk all that stuff. Read the i4b notes in the FreeBSD subdirectory if you're not on 0.81.12 or higher already. --- Gary Jennejohn Thanks heaps ! I am running 0.81.12, that is the latest developers' release. --- Gary Jennejohn Home - [EMAIL PROTECTED] Work - [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)
"Daniel C. Sobral" [EMAIL PROTECTED] wrote: OTOH, though, FreeBSD's malloc() is very unlikely to return an out of memory error. Why is that? What happens if the process hits its resource limits? Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] 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, Warner Losh wrote: In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : Good idea. I'll have it check to see that it's a regular file. Make sure that you do this with the stat, open, fstat interlocking so that there isn't a race here. I have this fixed in my latest code (on freefall of course). I did not use an original stat because that's pointless, as it adds another race condition. The only downside to my approach is that if it's a symlink to a dev, the dev can get opened/closed, and d_open/d_close be called. Warner 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: Replacement for grep(1) (part 2)
Jon Ribbens wrote: "Daniel C. Sobral" [EMAIL PROTECTED] wrote: OTOH, though, FreeBSD's malloc() is very unlikely to return an out of memory error. Why is that? Because memory (as in *real* memory, either RAM or swap) is allocated on-demand. So you can allocate any amount of virtual memory that the system can possibly provide you, even though you'll run out of memory much earlier, because other resources are also consuming it. What happens if the process hits its resource limits? If the system runs out of memory, the biggest process is killed. It might or might not be the one demanding additional memory. -- 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: Replacement for grep(1) (part 2)
"Daniel C. Sobral" [EMAIL PROTECTED] wrote: OTOH, though, FreeBSD's malloc() is very unlikely to return an out of memory error. Why is that? Because memory (as in *real* memory, either RAM or swap) is allocated on-demand. So you can allocate any amount of virtual memory that the system can possibly provide you, even though you'll run out of memory much earlier, because other resources are also consuming it. 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? What happens if the process hits its resource limits? 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). Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : I have this fixed in my latest code (on freefall of course). I did not : use an original stat because that's pointless, as it adds another race : condition. The only downside to my approach is that if it's a symlink : to a dev, the dev can get opened/closed, and d_open/d_close be called. How does the original stat add a race condition. You stat the file, open it, then fstat it. If the two match you know you're good. If they don't, you can detect that something bad has happened Warner 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 [EMAIL PROTECTED] writes: "Daniel C. Sobral" [EMAIL PROTECTED] wrote: OTOH, though, FreeBSD's malloc() is very unlikely to return an out of memory error. Why is that? Because FreeBSD overcommits memory. You can allocate (almost) as much memory as you want regardless of how much RAM / swap you have. You won't run into trouble unless you actually try to use too much of it. What happens if the process hits its resource limits? Malloc() fails with ENOMEM. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rtfm rewritten in C
On Sun, Jul 11, 1999, Brian F. Feldman wrote: I can manage C code much better than I can manage Perl code and C is faster than Perl. Trying to start ANOTHER holy war? :) I meant that you don't have to compile/interpret/whatever-you-wanna-call-it with compiled C code as you do with Perl. Plus the first -- I'm terrible with keeping Perl code managed. -- Chris Costello[EMAIL PROTECTED] To be, or not to be, those are the parameters. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rtfm rewritten in C
On Sun, 11 Jul 1999, Chris Costello wrote: On Sun, Jul 11, 1999, Brian F. Feldman wrote: I can manage C code much better than I can manage Perl code and C is faster than Perl. Trying to start ANOTHER holy war? :) I meant that you don't have to compile/interpret/whatever-you-wanna-call-it with compiled C code as you do with Perl. Plus the first -- I'm terrible with keeping Perl code managed. I agree. Perl, while more flexible, can be MUCH more of a mess. -- Chris Costello[EMAIL PROTECTED] To be, or not to be, those are the parameters. 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: PCCARD and Vpp voltage
In message [EMAIL PROTECTED] Wes Peters writes: : Didn't my message from yesterday make it to the list? On card insert, : you're supposed to read the voltage requirements for Vcc and apply *that* : voltage to Vcc, Vpp1, and Vpp2. If it did, I missed it... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : Ahh, I misunderstood you. In _this_ case you just proposed, the stat is : really pointless. What good would it do? It would let you know if you should even try to open the file... But that doesn't solve the race. The fstat tells you if what you opened was what you thought you were opening... However, for this, the original stat might not be completely necessary unless you were trying to specifically detect someone trying to race you. You are right that it won't buy you anything. I was confusing this with the tree walking case. The stat + fstat check there was needed... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel Drivers
[redirecting to -hackers] On Monday, 12 July 1999 at 12:44:18 +1000, Anthony Wyatt wrote: Hi, I really don't know where to post this message, so if there is a better place please let me know. Well, to quote the frequent posting to this newsgroup, If the question is of a general nature, ... ask FreeBSD-questions. Examples might be questions about installing FreeBSD or the use of a particular UNIX utility. If the question relates to enhancements to FreeBSD, and you can make suggestions about how to implement them, then send the message to FreeBSD-hackers. If the question is of particularly technical nature, such as implementation details or suggestions for improvements, then send the message to FreeBSD-hackers. I think this qualifies as one of the last two, so -hackers is the place. I want to write a driver for my video card, not for X, for my own home grown app :-) I've just read Chap 5 of the Magic Garden Explained (SysVR4 Internals) so I have some idea whats expected when writing a device driver. As you say, the Magic Garden is for System V. BSD is a little different, though not too much. I've also read the technical programming doco for my video card. The big hole in my plan is PCI. I don't know how to talk to my video card on the PCI bus :-( So I guess my questions are: Should I try and find out more about basic driver programming, specifically freeBSD, Yes. and if so where? UTSL. And -hackers. There's some stuff in section 9 of the manual, but it's not quite the level of completeness you'd find in the ddi/ddk docco. Where can I find out about programming PCI devices? UTSL. And -hackers. In particular, the PCI drivers are in /usr/src/sys/pci. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html 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: Kernel Drivers
Hmm... perhaps if Anthony is willing we can use his experience to help us further document the procedure for writing a FreeBSD PCI device driver? -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Raid software
[moving to -questions; this isn't a technical discussion] On Sunday, 11 July 1999 at 17:49:13 -0400, Andrew Willis wrote: What Raid software is available for FreeBSD? I cant seem to find much information on this issue. I would rather not dish out lots of $$$ for hardware Raid. Any suggestions would be appreciated.. Look at Vinum (http://www.lemis.com/vinum.html). Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html 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: Kernel Drivers
-Original Message- From: David E. Cross [mailto:[EMAIL PROTECTED]] Sent: Monday, July 12, 1999 1:14 PM To: Greg Lehey Cc: Anthony Wyatt; FreeBSD Hackers; [EMAIL PROTECTED] Subject: Re: Kernel Drivers Hmm... perhaps if Anthony is willing we can use his experience to help us further document the procedure for writing a FreeBSD PCI device driver? If everything goes to plan and works I'd be glad to write some doco about what I did. After I finish with my PCI video card I intend to try and write an AGP driver too. This would probably be easiest if you told me where I can find all the existing device driver and PCI programming doco, and any other relevent doco, so as to avoid re-inventing the wheel. Then it will probably be a wait and see if I can figure out what I need to do :-) Anthony To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCCARD and Vpp voltage
In message [EMAIL PROTECTED] Wes Peters writes: : From this, I'd say the card inserted event should read the Vcc wanted : value (from the Socket Present State Register?) and apply THAT voltage : to Vcc, Vpp1, and Vpp2, rather than just applying 5.0 volts. You might : seriously damage any 3.3v card inserted by applying 5v to it. Agreed on GPs. I don't think any laptops today have the low voltage slot, but instead have the unified slot. I believe that I saw in there that cards needed to be able to handle 5V as well, but in the world of PC Cards it is much better to be safe than sorry For the moment, the 0 - 50 change is good, but longer term we may need to do the 3.3V stuff correctly. BTW, does anybody know where I can get a type II CF slot to Type II PC Card card adapter? This is so I can plug a pc card into a CF slot (I have one that does the other way round, but want to compare the price of the adapter with the price of a ne2000 CF ethernet card I'm looking at ($130)). : This is a pretty good book, by the way. ISBN 0-201-40997-6. Agreed. That's where I got my ideas about PCCARD as well, since the promised standard hasn't appeared on my doorstep yet. Warner 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, Kevin Day wrote:
Is it worth it to write an identd for FreeBSD? With one sysctl added, it's
trivial to implement. If an identd would be desired, then should I make a
separate one, or rewrite the current inetd's internal identd shim? I
don't see a reason for pidentd when we could have an identd built in by
me fixing inetd up, and it would all take up less space.
There is the question - what for? identd is of questionable use at best.
The best use of identd I have seen is crypted cookies that would allow
an attackee to identify an attacker in a non-privacy-invasive manner.
In 3 years of running this at an ISP, I have never seen it used in anger.
Under normal circumstances (${BIGNUM} Wintendo boxes running IRC
clients), the info given is completely useless.
Just to add a counter-point here, I run an ISP that offers shell accounts.
We get idiot customers using IRC for all sorts of nasty things at times, and
identd is the only method I have for knowing who did it when I get
complaints.
However, pidentd is rather buggy of late, and tends to freak out a lot. If
we could have an 'official' identd, I'd like it. :)
Go ahead and try out mine then! You'll need the following patches from
http://www.FreeBSD.org/~green/ :
socred.patch (not necessary for 4.0; some parts require manual attention in
3.X, as it won't patch perfectly; this is already applied in 4.0)
getcred.patch
inetd_ident.patch
Patch them in in order, making sure they apply correctly. Then make includes,
rebuild the kernel, rebuild modules, install kernel and modules, rebuild
inetd, edit inetd.conf to enable the built-in auth service, and
reboot. Let me know how it goes. I hope to make this standard as part of 4.0 :)
Kevin
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: a BSD identd
The whole point of ident was -- and still is -- to authenticate or verify who created a specific TCP connection. If the machine is untouched (i.e., has not had the root account compromised), then ident responses are usually trustworthy enough. It is generally not applicable to single user operating systems like Windows, Mac OS, or DOS. ...in other words it is not applicable to the vast majority of operating systems where it is used. Where is ident used? Predominantly with IRC, with a minority holding in tcp_wrappers and mail servers. In a hard wrapping environment, by the time you need ident, it is most likely compromised. 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: a BSD identd
Just because it's useless in some situations doesn't mean it's not useful in others. Yours is an argument against _misusing_ identd, not an argument against _using_ it. No. It is an argument against trusting it. :-) 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: hardware
a...@isis.aye.net wrote: Given your experience, Could you please inform me of which sound card and video display adapter works best with FreeBSD. OSS which is third party sound driver, support FreeBSD. It's only US$20 and support KLM for FreeBSD-3-stable. http://www.4front-tech.com/ MIHIRA Sanpei Yoshiro 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)
Assar Westerlund wrote: And besides, I really don't think this is a grep function but actually is useful for programs that don't have any strategy for handling out of memory errors and might as well die (with a descriptive error message, of course). Let's call it emalloc and let's put in somewhere where it can be used. Too simple to warrant that, and other programs will likely want to handle the error differently. I don't agree. 1. this is a small function, but it's useful in lots of programs 2. that helps lazy programmers write code that actually checks for error returns instead of just ignoring them 3. it helps lots of programs that don't do anything intelligent (or for which there isn't much bright things to do) when allocating memory fails 4. having it in a library means it's more likely to be correct (i.e. sz == 0) but then again, I don't get to decide what goes in *BSD libc/libutil. In my library there's already a emalloc, ecalloc, and erealloc. OTOH, though, FreeBSD's malloc() is very unlikely to return an out of memory error. -- 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 01:49:59 -0400, Brian F. Feldman wrote: inetd already has the built-in equivalent to that. Maybe it's possible to make a REAL ident (*cough* the one I wrote) an option, inetd has that service off by default. That sounds much more like it. I will say that I suspect this is a bad move. The more I think about it, the more I think we don't want the kitchen sink in there. Inetd only offers a limited auth service to prevent delays in the servicing of requests from local users on remote hosts. Anyone who wants to use the auth service for other things should probably use a specialized piece of software to do that. I don't think inetd needs this functionality built in. I think that what you really want is pidentd imported into the base system. And while it's noble to want a GNU-free base system and I applaud efforts in that direction, you should probably slow down and read pidentd's license agreement. :-) Personally, I don't think there's anything wrong with leaving pidentd as a port. Then the user can select one of two lines for a real ident service or a fake one. DES has some interesting ideas in this direction. Take a look at closed PR 11796 if and when you start thinking about how to implement this. 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 00:49:59 EST, Kevin Day wrote: However, pidentd is rather buggy of late, and tends to freak out a lot. If we could have an 'official' identd, I'd like it. :) I hope you can back that up with more than a desire to see an official identd, whatever that means. Can you actually give examples of buggy behaviour? If so, I'd suggest sending in a PR, not discussing it here. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PCCARD and Vpp voltage
I'm not sure. There are low voltage cards and I'm not sure how they would like having 5V applied to Vpp to them. Again, I've not looked up the standards The low-voltage cards are keyed so you cannot plug them into 5v slots; perhaps the dual-voltage slots have protective circuitry that co-operates with this? 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: Budget on user-ppp
Brian Somers wrote: The i4b stuff seems to have some sophisticated costing control code (isdn.rates). It appears that you can define the costs at different times of day and thereby vary the timeouts, etc. I wonder whether any of this can be adapted for modem ppp. I've added it to my todo list. I'll probably look at the BACP or MP+ stuff first though, and then at the ``when to bring up another link'' code all fun games :-) Well? It's sunday... are you going through a slow week, for a change? :-) -- 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 don't see a point to that. However, I am finished. Please go to
http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch.
Hmm,
+#ifdef FAKEID
+ snprintf(fakeid_path, sizeof(fakeid_path), %s/.fakeid,
pw-pw_dir);
+ fakeid = fopen(fakeid_path, r);
+ if (fakeid) {
$ ln -s /etc/master.passwd ~/.fakeid
Ouch. (One possible saving grace here is that you truncate
after 16 characters).
+ if (!*cp || getpwnam(cp)) {
+ pw = getpwuid(uc.cr_uid);
+ cp = pw-pw_name;
+ goto printit;
+ }
What is this code trying to do? If the ~/.fakeid file is invalid
or the user is attempting to impersonate another then revert? A
comment would be nice. You forget to check for pw == NULL here
(but you don't earlier ;) and I don't think the goto is necessary.
Regards,
Niall
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Anybody porting Apple´s Darwin Streaming Server back to FreeBSD?
On 1999-07-09 18:18 +0200, Christoph Sold c...@cheasy.de wrote: Hi Folks, the subject says it all: does anybody work on porting Apple´s Darwin Streaming Server to FreeBSD? I do not want to duplicate the process... Here is my attempt at a port. I had no time to test it, though, but the build seems to be OK, and the binaries don't drop core immediately ;-) I made some assumptions in the patches for the PTHREAD_MUTEX_RECURSIVE_NP argument passed to pthread_mutexattr_setkind_np(), see patch-ab and -af, which may be just signs of pure optimism. Didn't check the sources of the pthreads library to see whether my assumption (PTHREAD_MUTEX_RECURSIVE_NP may be defined as PTHREAD_MUTEX_RECURSIVE) is correct or not. I just wanted get the build to complete ... Regards, STefan quicktime-server.port.tar.gz Description: application/tar-gz
system panics from Real Audio G2 player with ppp
Anyone else seeing system crashes under -current or other versions with user mode ppp. I can trigger an immediate crash supervisor write page not found from process ppp in from my wife's machine by running the Real Player G2 machine and hitting the ABC news link or any other site with a video stream. (I'm doing network address translation with the built in IP aliasing. Connecting with audio mostly only streams works ok). I haven't been able to get savecore to recover a working crash dump. A ppp from Feb 9th that I had on the system works perfectly with the same system. -r-sr-xr-- 1 root network 186916 Feb 9 20:30 /usr/sbin/ppp -r-sr-xr-- 1 root network 234056 Jul 11 12:23 /usr/sbin/ppp Bill --- bpech...@shell.monmouth.com|pech...@pechter.dyndns.org Three things never anger: First, the one who runs your DEC, The one who does Field Service and the one who signs your check. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In article 199907102150.paa33...@harmony.village.org, Warner Losh i...@village.org wrote: Some ftpd and sendmail servers make the queries. When I have my fake identd in place, they go much faster... :-) Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. The only way a long timeout can occur is if you have a filter rule installed that drops the incoming packets without responding to them. You can block the incoming packets but still avoid the timeout with a filter rule that sends back a reset: add reset tcp from any to any auth setup in via etha16 John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Budget on user-ppp
Brian Somers wrote: The i4b stuff seems to have some sophisticated costing control code (isdn.rates). It appears that you can define the costs at different times of day and thereby vary the timeouts, etc. I wonder whether any of this can be adapted for modem ppp. I've added it to my todo list. I'll probably look at the BACP or MP+ stuff first though, and then at the ``when to bring up another link'' code all fun games :-) Well? It's sunday... are you going through a slow week, for a change? :-) No, I'm waiting for h...@freebsd.org to commit my i4b changes. He's waiting for feedback from the development sources he released a few days ago. I've only got as far as reading the BACP rfc, but ppp works multilink over ISDN now (but hasn't yet been committed). -- Daniel C. Sobral (8-DCS) d...@newsguy.com d...@freebsd.org I'm one of those bad things that happen to good people. -- Brian br...@awfulhak.orgbr...@freebsd.org http://www.Awfulhak.org br...@openbsd.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
Nick Hibma wrote: For your information http://www.mapblast.com specifies LongLat at the bottom of the page when you are looking at a map. Just move the icon to the right place. Aha! I can get my ICBM coordinates at last! Lat: 36.4544 Lon: 139.3704 Or: Lat: 36° 27' 15 N Lon: 139° 22' 13 E -- 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: Pictures from USENIX
David Greenman wrote: A constant 5 o'clock shadow, maybe, but not a beard. And what's wrong with a beard? Nothing. I just remember someone pointing out in a previous e-mail that all the core members had some sort of beard. Very few core members have beards, so whoever said that was wrong. I think it's the wizened old hands image Jordan once provided... :-) Anyway, why did Jordan choose an avatar without beard to go to Usenix? -- 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
rtfm rewritten in C
So far, it seems the functionality is the same. A tarball is availible at http://www.calldei.com/~chris/rtfm.tar.gz It uses libfetch, and it does not use pcre as someone has suggested. It still needs decent case-insensitivity code, and as far as I know, there's no case-insensitive strstr, but I might attempt to work on one. -- Chris Costelloch...@calldei.com Life would be so much easier if we could just look at the source code. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: question: delay of a context - switch
On 1999-07-09 08:54 +0200, Thomas Klein kl...@kryptokom.de wrote: Dose anyone know how long a the kernel is busy with context switching (beetween two processes) ? Has anyone tested this yet? I estimate of about 7 usec duration for that, (on a Pentium 400) but I think that's to long. There is a port of Larry McVoy's Benchmarks in benchmarks/lmbench, which (as one small part of the benchmark suite) accurately measures context switching overhead in a number of different situations (number of active processes, data segment size). The context switch time depends on a number of parameters, it is not a constant of the CPU and OS. I see 6us on my Celeron 300A when there is no active data and there are only two active processes, 9us with 16 active processes, and 33us with 16 processes that each keep 1MB of memory active. SMP kernels have additional task switch overhead, but I can't offer any data before tomorrow, when I'll run those tests on my systems at work ... Gruß, STefan 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 00:49:59 EST, Kevin Day wrote: However, pidentd is rather buggy of late, and tends to freak out a lot. If we could have an 'official' identd, I'd like it. :) I hope you can back that up with more than a desire to see an official identd, whatever that means. Can you actually give examples of buggy behaviour? If so, I'd suggest sending in a PR, not discussing it here. Ciao, Sheldon. Please see: ports/12596 (just added) ports/8042 Thanks, Kevin 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, Sheldon Hearn wrote: On Sun, 11 Jul 1999 01:49:59 -0400, Brian F. Feldman wrote: inetd already has the built-in equivalent to that. Maybe it's possible to make a REAL ident (*cough* the one I wrote) an option, inetd has that service off by default. That sounds much more like it. I will say that I suspect this is a bad move. The more I think about it, the more I think we don't want the kitchen sink in there. Inetd only offers a limited auth service to prevent delays in the servicing of requests from local users on remote hosts. Anyone who wants to use the auth service for other things should probably use a specialized piece of software to do that. I don't think inetd needs this functionality built in. I think that what you really want is pidentd imported into the base system. And while it's noble to want a GNU-free base system and I applaud efforts in that direction, you should probably slow down and read pidentd's license agreement. :-) Personally, I don't think there's anything wrong with leaving pidentd as a port. I find pidentd gross, to say the least. I don't see why not to kill it... And this service is very small, so it doesn't make inetd huge. It's not feeping creaturism because I replaced the ident service there with a working one. Then the user can select one of two lines for a real ident service or a fake one. DES has some interesting ideas in this direction. Take a look at closed PR 11796 if and when you start thinking about how to implement this. Ciao, Sheldon. 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: a BSD identd
On Sun, 11 Jul 1999, Niall Smart wrote:
I don't see a point to that. However, I am finished. Please go to
http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch.
Hmm,
+#ifdef FAKEID
+ snprintf(fakeid_path, sizeof(fakeid_path), %s/.fakeid,
pw-pw_dir);
+ fakeid = fopen(fakeid_path, r);
+ if (fakeid) {
$ ln -s /etc/master.passwd ~/.fakeid
Ouch. (One possible saving grace here is that you truncate
after 16 characters).
Good idea. I'll have it check to see that it's a regular file.
+ if (!*cp || getpwnam(cp)) {
+ pw = getpwuid(uc.cr_uid);
+ cp = pw-pw_name;
+ goto printit;
+ }
What is this code trying to do? If the ~/.fakeid file is invalid
or the user is attempting to impersonate another then revert? A
comment would be nice. You forget to check for pw == NULL here
(but you don't earlier ;) and I don't think the goto is necessary.
If pw lookup for that uid succeeded before, why won't it succeed now? In
fact, I didn't even need the pw = , but that would be depending on
current static behavior...
Regards,
Niall
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: a BSD identd
On Sun, 11 Jul 1999 14:03:29 -0400, Brian F. Feldman wrote: And this service is very small, so it doesn't make inetd huge. It's not feeping creaturism because I replaced the ident service there with a working one. Perhaps this is where we're missing each other. The ident service supplied with inetd isn't broken, it's just designed to do something different from what your replacement was designed to do. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
John Polstra wrote: In article 199907102150.paa33...@harmony.village.org, Warner Losh i...@village.org wrote: Some ftpd and sendmail servers make the queries. When I have my fake identd in place, they go much faster... :-) Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take NO for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Whether this behavior is good or not begs the question, that is how it works. I'd also like to throw in some thoughts on ident in general, since I have several years of experience both in IRC administration and having been through this debate several times. :) 1. ident is useful as far as it goes. It shouldn't be trusted as authentication, but it can give you a good idea of where to start when tracking down problem users. 2. Most shell services do a good job of keeping ident reliable. They need to do that because most IRC networks heavily penalize clients that don't return any ident. 3. Having a built in version of a real ident run out of inetd would be *very* welcome by the people that need it. pidentd is a bloated, buggy pig. 4. I agree with Sheldon that returning real responses by default would be a bad thing. The current ability to send fake responses is a good thing, but having the option to do real ident would also be good. 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. HTH, Doug 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:54:03 EST, Kevin Day wrote: Please see: ports/12596 (just added) ports/8042 Thanks! I've seen 8042 before, but yours looks a lot more useful, as I can't make sense of the older one. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
Doug wrote: John Polstra wrote: Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take NO for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. Whether this behavior is good or not begs the question, Agreed. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Budget on user-ppp
Brian Somers writes: Daniel C. Sobral wrote: Well? It's sunday... are you going through a slow week, for a change? :-) No, I'm waiting for h...@freebsd.org to commit my i4b changes. He's waiting for feedback from the development sources he released a few days ago. I've only got as far as reading the BACP rfc, but ppp works multilink over ISDN now (but hasn't yet been committed). The last I heard on the ISDN-developers' list was that you're working on fixing bugs ? HOW do I use i4b with user-ppp ? There's not the least hint of any information in the latest developers' release regarding that. Whine. I want to test it. --- Gary Jennejohn Home - ga...@muc.de Work - ga...@fkr.dec.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
John Polstra wrote: Doug wrote: John Polstra wrote: Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take NO for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. No, they connect(). If it times out (eg: packet filter), it kicks you out. If it gets through and the ident server doesn't respond within the 30 second timeout, it drops you again. If it connects and gets a 'Warm-Fuzzy' or an error of some sort, it drops you. If it gets a non-UNIX username response, it kicks you out. Basically, to use a well connected irc server, you *must* run an identd that returns a valid username response, and that username is used in your conversations. Some servers will let you on without a fully functional identd, but in my experience they seem to be the most unreliable as they are the most abused. ISP's run identd on their shell servers. That's so that when their servers get banned from IRC, they can find out which of their shell users from their shell users to have taken out and shot. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
1. ident is useful as far as it goes. It shouldn't be trusted as
authentication, but it can give you a good idea of where to start when
tracking down problem users.
First thing you say to yourself after a compromise is trust nothing.
Things like idents can/will/should/are targets.
2. Most shell services do a good job of keeping ident reliable. They need
to do that because most IRC networks heavily penalize clients that don't
return any ident.
This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
answers like HAX0r, there is little point, except for the administrator
of the box _giving_ the ident. If that was me, it would be _low_ on my
list.
3. Having a built in version of a real ident run out of inetd would be
*very* welcome by the people that need it. pidentd is a bloated, buggy pig.
Small set of people. Much larger set of dupes who would believe/trust
this.
4. I agree with Sheldon that returning real responses by default would be
a bad thing. The current ability to send fake responses is a good thing,
but having the option to do real ident would also be good.
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.
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: support for i386 hardware debug watch points
Shouldn't this patch be investigated/integrated into the beta sources of gdb at sourceware.cygnus.com? Marty Leisner 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, Doug wrote: 3. Having a built in version of a real ident run out of inetd would be *very* welcome by the people that need it. pidentd is a bloated, buggy pig. Thank you. That's why I wrote it. 4. I agree with Sheldon that returning real responses by default would be a bad thing. The current ability to send fake responses is a good thing, but having the option to do real ident would also be good. 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. How in the world could my inetd ident service be exploited? I just fixed the only problematic feature, fake id, to make it not read anything but a regular file and not let you try to use someone else's name. I can't see any way that any part of it could be exploited... HTH, Doug 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: a BSD identd
: 2. Most shell services do a good job of keeping ident reliable. They need
: to do that because most IRC networks heavily penalize clients that don't
: return any ident.
:
:This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
:answers like HAX0r, there is little point, except for the administrator
:of the box _giving_ the ident. If that was me, it would be _low_ on my
:list.
ident is extremely useful when taken in the proper context. It doesn't
really matter what a user-owned box returns. An IRC administrator only
cares about two things:
* If the irc client is connecting from an (ISP's) multi-user shell
machine, that the ident contain sufficient information to identify
the user.
* If the irc client is connecting from a single-user machine, such as
a windoz box, the IRC administrator has the IP address and times
involved, which is again sufficient for the user's ISP to identify
the user.
When a user is abusing an IRC server, the IRC administrator has two
choices:
* If it is coming from an ISP who takes abuse seriously, the IRC
administrator need only identify the user sufficiently (IP and time,
or ident info if coming from a shared shell box) such that the ISP
can kick the user off the service.
* If it is coming from an ISP who does not take abuse seriously, the
IRC administrator locks out the entire ISP.
At BEST ident was turned on on all machines and it returned the user's
real user name. It did that because it made it a whole lot easier for us
to handle abuse issues, it cut abuse significantly, and it cut
abuse-related email from remote IRC admins significantly because they
could lockout specific users based on the ident info without having to
contact us.
I don't work at BEST any more, but I would love to see kernel support
for ident lookups. To make identd work reasonably well, I had to hack
the server to timeout after a few seconds worth of cpu-bound searching
through KVM, because it would sometimes get into scanning loops.
-Matt
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
:How in the world could my inetd ident service be exploited? I just fixed :the only problematic feature, fake id, to make it not read anything but a :regular file and not let you try to use someone else's name. I can't see :any way that any part of it could be exploited... Typically the exploitation of identd is in the form of a denial-of-service attack. What we saw at BEST were denial-of-service attacks against identd to prevent users on a particular shell machine from being able to initiate an IRC client session (because the remote IRC server would not be able to obtain ident info). Early versions of Identd could be used for port scanning purposes, but not any more. Since identd will only resolve connections comming from the client IP making the connection, there aren't very many interesting ways to abuse it. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
Mark Murray wrote:
1. ident is useful as far as it goes. It shouldn't be trusted as
authentication, but it can give you a good idea of where to start when
tracking down problem users.
First thing you say to yourself after a compromise is trust nothing.
Things like idents can/will/should/are targets.
Sure, but I don't think that compromised boxes are the norm, unless I'm
missing something here.
2. Most shell services do a good job of keeping ident reliable. They need
to do that because most IRC networks heavily penalize clients that don't
return any ident.
This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
answers like HAX0r, there is little point, except for the administrator
of the box _giving_ the ident. If that was me, it would be _low_ on my
list.
I'm talking shell services, not ISP's. All of the large IRC networks
have
either implemented a global ban system (like dalnet and undernet) or have a
kline information sharing system (like efnet and ircnet) that allows them
to effectively prevent access from the shell system to IRC. Since most
shells are sold for IRC, the administrators of these systems are doing
everything they can to cooperate with the IRC networks in tracking problem
users, and ident is one of the tools to help do this. I agree that windows
users being able to supply their own ident makes it less valuable in the
general case, but not completely unvaluable.
3. Having a built in version of a real ident run out of inetd would be
*very* welcome by the people that need it. pidentd is a bloated, buggy pig.
Small set of people. Much larger set of dupes who would believe/trust
this.
How much code is in the system now that benefits a small set of
people?
That said, I am definitely an anti-bloatist and would almost prefer that
this identd be a port. But from what Brian is saying it sounds like this
would be a very small addition, and for those few people that need it this
would be a huge benefit. I believe the cost:benefit analysis comes out in
favor of including it, but perhaps my perspective is biased.
4. I agree with Sheldon that returning real responses by default would be
a bad thing. The current ability to send fake responses is a good thing,
but having the option to do real ident would also be good.
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.
Yes, I agree wholeheartedly with this point.
Doug
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: rtfm rewritten in C
On Sat, 10 Jul 1999, Chris Costello wrote: It still needs decent case-insensitivity code, and as far as I know, there's no case-insensitive strstr, but I might attempt to work on one. this is done: http://big.endian.org/~bright/freebsd/rtfm/rtfm.c 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, Matthew Dillon wrote:
: 2. Most shell services do a good job of keeping ident reliable. They need
: to do that because most IRC networks heavily penalize clients that don't
: return any ident.
:
:This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
:answers like HAX0r, there is little point, except for the administrator
:of the box _giving_ the ident. If that was me, it would be _low_ on my
:list.
ident is extremely useful when taken in the proper context. It doesn't
really matter what a user-owned box returns. An IRC administrator only
cares about two things:
* If the irc client is connecting from an (ISP's) multi-user shell
machine, that the ident contain sufficient information to identify
the user.
* If the irc client is connecting from a single-user machine, such as
a windoz box, the IRC administrator has the IP address and times
involved, which is again sufficient for the user's ISP to identify
the user.
When a user is abusing an IRC server, the IRC administrator has two
choices:
* If it is coming from an ISP who takes abuse seriously, the IRC
administrator need only identify the user sufficiently (IP and time,
or ident info if coming from a shared shell box) such that the ISP
can kick the user off the service.
* If it is coming from an ISP who does not take abuse seriously, the
IRC administrator locks out the entire ISP.
At BEST ident was turned on on all machines and it returned the user's
real user name. It did that because it made it a whole lot easier for us
to handle abuse issues, it cut abuse significantly, and it cut
abuse-related email from remote IRC admins significantly because they
could lockout specific users based on the ident info without having to
contact us.
I don't work at BEST any more, but I would love to see kernel support
for ident lookups. To make identd work reasonably well, I had to hack
the server to timeout after a few seconds worth of cpu-bound searching
through KVM, because it would sometimes get into scanning loops.
Well, it's here now. I've committed it in 4.0, and would MFC it except it
would require the struct socket changes I made in -CURRENT. See my pidentd
freebsd.c replacement (using this) at http://www.FreeBSD.org/~green/freebsd4.c
-Matt
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: Budget on user-ppp
Brian Somers writes: Daniel C. Sobral wrote: Well? It's sunday... are you going through a slow week, for a change? :-) No, I'm waiting for h...@freebsd.org to commit my i4b changes. He's waiting for feedback from the development sources he released a few days ago. I've only got as far as reading the BACP rfc, but ppp works multilink over ISDN now (but hasn't yet been committed). The last I heard on the ISDN-developers' list was that you're working on fixing bugs ? HOW do I use i4b with user-ppp ? There's not the least hint of any information in the latest developers' release regarding that. Whine. I want to test it. Fair 'nuff. ftp://ftp6.uk.FreeBSD.org/pub/PPPoISDN at your own risk all that stuff. Read the i4b notes in the FreeBSD subdirectory if you're not on 0.81.12 or higher already. --- Gary Jennejohn Home - ga...@muc.de Work - ga...@fkr.dec.com -- Brian br...@awfulhak.orgbr...@freebsd.org http://www.Awfulhak.org br...@openbsd.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: rtfm rewritten in C
On Sat, Jul 10, 1999 at 11:45:39PM -0500, Chris Costello wrote: So far, it seems the functionality is the same. A tarball is availible at http://www.calldei.com/~chris/rtfm.tar.gz What was the advantage of rewriting it in C? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: rtfm rewritten in C
On Sun, Jul 11, 1999, Tim Vanderhoek wrote: On Sat, Jul 10, 1999 at 11:45:39PM -0500, Chris Costello wrote: So far, it seems the functionality is the same. A tarball is availible at http://www.calldei.com/~chris/rtfm.tar.gz What was the advantage of rewriting it in C? I can manage C code much better than I can manage Perl code and C is faster than Perl. -- Chris Costelloch...@calldei.com If you have a procedure with 10 parameters, you probably missed some. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: rtfm rewritten in C
On Sun, 11 Jul 1999, Chris Costello wrote: On Sun, Jul 11, 1999, Tim Vanderhoek wrote: On Sat, Jul 10, 1999 at 11:45:39PM -0500, Chris Costello wrote: So far, it seems the functionality is the same. A tarball is availible at http://www.calldei.com/~chris/rtfm.tar.gz What was the advantage of rewriting it in C? I can manage C code much better than I can manage Perl code and C is faster than Perl. Trying to start ANOTHER holy war? :) -- Chris Costelloch...@calldei.com If you have a procedure with 10 parameters, you probably missed some. 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
Raid software
What Raid software is available for FreeBSD? I cant seem to find much information on this issue. I would rather not dish out lots of $$$ for hardware Raid. Any suggestions would be appreciated.. Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
ARP questions
I'm going to take a crack at cleaning up arp(8), but I need hear some specific answers from someone who's worked with the ARP subsystem: 1) What's the purpose of the sin_other field of a struct sockaddr_inarp (which is either set to 0 or SIN_PROXY)? 2) What's the difference between a published or published (proxy only) ARP table entry (as reported by arp(8))? 3) Should a proxy ARP entry be a host route (i.e. RTF_HOST is set) as I suspect, or a net route with a /32 netmask, as it strangely seemed to be for published entries before arp(8) broke in -STABLE? For either case, why? 4) If I want to perform proxy ARP on directly attached Ethernet network A for a host on directly attached Ethernet network B, do I actually need two ARP table entries--one published (proxy only) entry to allow for the proxying on network A, and another ordinary entry (which may in fact be automatically created through the normal ARP mechanism) to actually forward packets to the host on network B? Cheers, Mick The Reverend Jasper P. O'Malley dotdot:jo...@webnology.com Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message 199907112034.waa17...@gratis.grondar.za, Mark Murray wrote: } 1. ident is useful as far as it goes. It shouldn't be trusted as } authentication, but it can give you a good idea of where to start when } tracking down problem users. } } First thing you say to yourself after a compromise is trust nothing. } Things like idents can/will/should/are targets. As has been said over and over, identd isn't useful to track a compromise of the machine running it, but can be useful if machine A is running it and hasn't been compromised, and machine A is used to break into machine B. Of course even then you have to be careful about trusting logs, but in a well set up environment it's certainly better than nothing. And it's useful for tracking abuse that's not related to breaking into machines. [ ... ] } 3. Having a built in version of a real ident run out of inetd would be } *very* welcome by the people that need it. pidentd is a bloated, buggy pig. } } Small set of people. Much larger set of dupes who would believe/trust } this. While that's true, I'll say again that it's an argument against _abusing_ identd and not an argument against _using_ it. You may not like/want/need it, but other people do, and not all of them are idiots. Just because someone else's usage model differs from yours doesn't make their experiences or desires invalid. -- Jon Hamilton hamil...@pobox.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In article local.mail.freebsd-hackers/19990711203203.b320...@overcee.netplex.com.au you write: response, it kicks you out. Basically, to use a well connected irc server, you *must* run an identd that returns a valid username response, and that username is used in your conversations. Some servers will let you on without a fully functional identd, but in my experience they seem to be the most unreliable as they are the most abused. Uh, not always. I've been on/off of IRC for the last, oh, 7 years or so, and _still_ don't bother to run identd. It's a nuisance, and as I'm the admin on my machines, I don't need it. I've always managed to find some well-run servers that don't require identd. -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message pine.bsf.4.10.9907111649160.27818-100...@janus.syracuse.net Brian F. Feldman writes: : How in the world could my inetd ident service be exploited? I just fixed : the only problematic feature, fake id, to make it not read anything but a : regular file and not let you try to use someone else's name. I can't see : any way that any part of it could be exploited... Typically how that was exploited is as a buffer overflow on the remote side (eg there was an exploit in sendmail where the attacker would send a very long string when the ident request came accross. Sendmail would record this in a fixed length buffer on the stack, which overflowed allowing an egg to execute). The text file that you read could be used to make it easier to setup such a hostile host, since if I recall correctly, the entire EGG was printable characters. There are no limits in the size of responses for ident... Thankfully, this exploit is long since dead. However, with irc servers using it as a honest people's lock to keep honest people honest maybe there is something that can be done there. Also, at one time one could open the ident service port up and just sit there, never sending data. After a short period of time, all the ident server slots would be in use, and then the attacker could begin to attack the remote side in earnest (this is a reason that I had forgotten why identd was considered to be a very weak protocol). There was also some trick of using identd to scan ports (eg, connect to identd and ask for each port, in succession, since some early identds weren't selective enough about the data they returned). I also recall seeing on some of the blacker lists that I've bumped into instructions for using TTCP and/or half open connections to confuse identd as well. I can't find the references right now, but these may also have boiled down to the TCP SYN-class of attacks that was so popular a while ago. There is also a danger in accepting source routed packets as well (which I think we turn off at the system level by default). They could be used to figure out who other connections belonged to by disguising the source address to be one other than the originator to gain information about any user connected to your machine. Well, you did ask how it might be abused :-) Warner 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 19990719.naa16...@gratis.grondar.za Mark Murray writes: : The low-voltage cards are keyed so you cannot plug them into 5v : slots; perhaps the dual-voltage slots have protective circuitry : that co-operates with this? Yes. The dual voltage cards are supposed to bring certain pins high and/or low to denote which voltages they like. In my brief reading of the Mindshare books, it appears that cards are only required to take 5V on Vcc, but aren't required to take it on Vpp. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message pine.bsf.4.10.9907111408060.25135-100...@janus.syracuse.net Brian F. Feldman writes: : Good idea. I'll have it check to see that it's a regular file. Make sure that you do this with the stat, open, fstat interlocking so that there isn't a race here. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message xfmail.990711131918@polstra.com John Polstra writes: : Really?? Even though their connect() call failed? Ick! I know : sendmail doesn't behave that way. I'll take your word about the IRC : daemons -- I don't know anything about them. Yes. At least that's what I've observed. However, I believe the culprit was a firewall that just dropped the packets for the connection request, so it had to wait 30 seconds to timeout. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Budget on user-ppp
Brian Somers writes: I want to test it. Fair 'nuff. ftp://ftp6.uk.FreeBSD.org/pub/PPPoISDN at your own risk all that stuff. Read the i4b notes in the FreeBSD subdirectory if you're not on 0.81.12 or higher already. --- Gary Jennejohn Thanks heaps ! I am running 0.81.12, that is the latest developers' release. --- Gary Jennejohn Home - ga...@muc.de Work - ga...@fkr.dec.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message 37890518.aa3d7...@gorean.org Doug writes: : Sure, but I don't think that compromised boxes are the norm, unless I'm : missing something here. The response doesn't have to come from the box being asked the question in order for it to be accepted. If you can load the box being asked highly enough, you can sniff the packets from another machine and then use that knowledge to win the race to make the connection. If you win the race, and the target machine responds, its answer will silently be tossed away. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
