Re: the future of sun4v
Marius Strobl wrote: On Fri, Aug 22, 2008 at 01:44:25PM +0200, Kris Kennaway wrote: Peter Jeremy wrote: [Replies re-directed to freebsd-sun4v] On 2008-Aug-21 14:42:55 -0700, Kip Macy [EMAIL PROTECTED] wrote: I believe that there is a general expectation by freebsd users and developers that unsupported code should not be in CVS. Although sun4v is a very interesting platform for developers doing SMP work, I simply do not have the time or energy to maintain it. If someone else would like to step up and try his hand I would be supportive of his efforts. In the likely event that no one steps forward by the time that 7.1 is released I will ask that it be moved to the Attic. Since there are no other current SPARC CPUs that FreeBSD can run on (the US-II has been obsolete for about 6 years and FreeBSD won't run on any more recent sun4u chips), that will also remove the justification for maintaining a SPARC64 port. I don't have the knowledge or available time to maintain the sun4v port by myself but would be happy to be part of a team doing so. One impediment I have is that I don't have a T-1 or T-2 system that I can dedicate to FreeBSD. I could work on FreeBSD in a guest domain - but since FreeBSD doesn't support either the virtual disk or virtual network, actually getting FreeBSD running there presents somewhat of a challenge. There are two t1000 systems in the freebsd.org cluster that are available for people to work on. Rink Springer has also expressed interest in this. Perhaps Kip can explain some more about what things he looked at, but the most serious bugs might be in pmap or perhaps trap handling. Operationally, things like buildworld -jN die quickly with random signals, kernel traps, etc. Kris P.S. It looks like marius has made progress on US III but sun4u is still an architectural dead end. Well, let's see what architecture the upcoming Rock CPUs are; judging their feature list they appear to be a continuation of the Fujitsu sun4u line rather than a successor of UST1/2 :) That's inaccurate. Rock is meant to be very compatible with sun4v, although I don't know if uname will say sun4v or something else...but you will need a bug-free sun4v operating system to run them (which is to say that various bugs in the solaris sun4v support needed to get fixed rather than left...) The critical issue for freebsd (and any operating system for that matter) on rock is how well does the kernel scale to a system with that many concurrent threads? Darren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Creation of the NO_SSP build knob
Ruslan Ermilov [EMAIL PROTECTED] writes: There's no possibility to easily make what you want, i.e., disable SSP for some parts of the tree. Doing it for particular makefiles OTOH should be pretty easy, by starting a makefile with the following two lines: That's not what Jeremie wants, that's what the Makefiles already do. Parts of the tree *can't* be built with SSP enabled, and the Makefiles set WITHOUT_SSP to disable it. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Creation of the NO_SSP build knob
Hello Dag-Erling, On Mon, Sep 08, 2008 at 01:16:16PM +0200, Dag-Erling Smørgrav wrote: Ruslan Ermilov [EMAIL PROTECTED] writes: There's no possibility to easily make what you want, i.e., disable SSP for some parts of the tree. Doing it for particular makefiles OTOH should be pretty easy, by starting a makefile with the following two lines: That's not what Jeremie wants, that's what the Makefiles already do. Parts of the tree *can't* be built with SSP enabled, and the Makefiles set WITHOUT_SSP to disable it. That's what the Makefiles already do indeed. Please excuse me if my english wasn't good enough to express it correctly. You are right to say that parts of the tree can't be build with SSP enabled. IMHO, the problem lies in the way it's enforced: using WITH_SSP shouldn't lead to a build error. The patch I sent along my reply to Ruslan corrects this. By the way, I think WITH_*/WITHOUT_* options should be user-only options and shouldn't be used in the source tree. This would avoid this kind of problem. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Extending find(1) to support -printf
Jeremy Chadwick wrote: On Fri, Sep 05, 2008 at 03:12:53AM -0700, Jeremy Chadwick wrote: Also, some folks on #bsdports asked why I was bothering with this in the first place: mutt supports backticks to run shell commands inside of a muttrc file. See Building a list of mailboxes on the fly below: http://wiki.mutt.org/?ConfigTricks Note the find ... -printf '%h ' method. I can accomplish (just about) the same using `echo $HOME/Maildir/*`, but if I want to exclude an entry, I can't use | grep -v, because mutt doesn't support pipes within backticks. :-) Follow-up: mutt's backtick support does in fact respect pipes. My echo|grep -v was doing exactly what I requested: the grep -v was removing all output of the echo, since echo returned the results in a space-delimited format, not one per line. Hence, mailboxes was being executed without any arguments. Equally as frustrating, mutt's backtick support will only honour the first line of input. If a backticked command returns multiple lines, only the first is read; the rest are ignored. Well, you can convert back and forth between spaces and newlines with tr(1): echo * | tr ' ' '\n' | grep -v whatever | tr '\n' ' ' It's not pretty, but it should work. Note that ls(1) prints one file name per line, so you can simplify the above line like this: ls | grep -v whatever | tr '\n' ' ' By the way, I often use zsh in such cases. It supports extended globbing, for example, the wildcard expression *~*.(gz|bz2) matches all files _except_ the ones that end with .gz or .bz2. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Temp files in /etc
Joshua Piccari wrote: I am setting up a few jails and I want them all to use the same /etc files (with the exception of the files related to the password files and databases), so I mounted a shared /etc folder as a nullfs with read-only permissions. The problem is that using utilities like pw or chpass create temporary files in /etc and that file system is mounted read-only. So is there a way to force any utilities that create temp files in /etc to use another location, something like /usr/local/etc for example? I had exactly the same problem. I wrote a small patch that solves it: http://www.secnetix.de/olli/FreeBSD/jail-passwd/ Please read the instructions.txt file first, then download the appropriate patch file. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With Perl you can manipulate text, interact with programs, talk over networks, drive Web pages, perform arbitrary precision arithmetic, and write programs that look like Snoopy swearing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
IPFW uid logging...
Hey all, I have the following rule set up in ipfw to limit the exposure of bad php scripts and trojans that try to send mail directly. allow tcp from any to any dst-port 25 uid root deny log tcp from any to any dst-port 25 out However, the log messages I get look like this: Sep 8 13:21:11 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:16 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 Sep 8 13:21:16 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58131 209.85.133.27:25 out via em0 Sep 8 13:21:28 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:32 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58131 209.85.133.27:25 out via em0 Sep 8 13:22:45 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:65313 64.202.166.12:25 out via em0 Sep 8 13:22:45 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:65313 64.202.166.12:25 out via em0 Sep 8 13:22:46 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:65313 64.202.166.12:25 out via em0 Sep 8 13:22:49 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:65313 64.202.166.12:25 out via em0 Which is to say, they don't include the UID -- and I have several hundred sites, each with its own UID. Yes, I could go ahead and set up a thousand deny rules, one for each UID -- but being able to log this info (since it IS being checked) would be great. Thoughts? -Dan Mahoney -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW uid logging...
In the last episode (Sep 08), Dan Mahoney, System Admin said: I have the following rule set up in ipfw to limit the exposure of bad php scripts and trojans that try to send mail directly. allow tcp from any to any dst-port 25 uid root deny log tcp from any to any dst-port 25 out However, the log messages I get look like this: Sep 8 13:21:11 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:16 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 Which is to say, they don't include the UID -- and I have several hundred sites, each with its own UID. Yes, I could go ahead and set up a thousand deny rules, one for each UID -- but being able to log this info (since it IS being checked) would be great. It should be possible to add a couple more arguments to ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the fw_ugid_cache struct. Then you can edit ipfw_log to print the contents of that struct if ugid_lookup==1. That would result in the logging of uid for any failed packet that had to go through a uid check on the way to the deny rule. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the future of sun4v
[cc list trimmed] On 2008-Sep-08 01:14:39 -0700, Darren Reed [EMAIL PROTECTED] wrote: The critical issue for freebsd (and any operating system for that matter) on rock is how well does the kernel scale to a system with that many concurrent threads? Right now it doesn't. And based on some previous threads, there is a lot of redesign to do before it can. But stability needs to come before scalability. There's no point in FreeBSD pretending it can support some arbitrary number of CPUs when it panics due to races in one of the CPU subsystems - which is my understanding of the current sun4v state. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpzdYg5W07ZM.pgp Description: PGP signature
Re: IPFW uid logging...
On Mon, 8 Sep 2008, Dan Nelson wrote: In the last episode (Sep 08), Dan Mahoney, System Admin said: I have the following rule set up in ipfw to limit the exposure of bad php scripts and trojans that try to send mail directly. allow tcp from any to any dst-port 25 uid root deny log tcp from any to any dst-port 25 out However, the log messages I get look like this: Sep 8 13:21:11 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:16 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 Which is to say, they don't include the UID -- and I have several hundred sites, each with its own UID. Yes, I could go ahead and set up a thousand deny rules, one for each UID -- but being able to log this info (since it IS being checked) would be great. It should be possible to add a couple more arguments to ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the fw_ugid_cache struct. Then you can edit ipfw_log to print the contents of that struct if ugid_lookup==1. That would result in the logging of uid for any failed packet that had to go through a uid check on the way to the deny rule. Okay, so if it's fairly easy to do, the question would be since I don't feel right hacking in this change myself -- how could I propose this as a feature? It's not a BUG per-se, but I think it could be useful to others as well. -Dan -- Pika Pika Pika! -Pikachu, of Pokemon fame. Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] Extending the ddb command set
Hello hackers,
I sent a patch some time ago, allowing modules to extend the ddb
command set. I just realized the link I provided then was in French so
that might have discouraged people from going any further. I have
therefore posted it here. Also, since I would like this patch to be
committed at some point, I have written a man page that I also
enclosed. Comments are welcome.
The man page:
.Dd August 27, 2008
.Dt DB_COMMAND 9
.Os
.Sh NAME
.Nm DB_COMMAND ,
.Nm DB_SHOW_COMMAND ,
.Nm DB_SHOW_ALL_COMMAND
.Nd Extends the ddb command set.
.Sh SYNOPSIS
.In ddb/ddb.h
.Fo DB_COMMAND
.Fa command_name
.Fa command_function
.Fc
.Fn DB_SHOW_COMMAND command_name command_function
.Fn DB_SHOW_ALL_COMMAND command_name command_function
.Sh DESCRIPTION
.Pp
The
.Fn DB_COMMAND
macro adds
.Fa command_name
to the list of top-level commands. Invoking
.Fa command_name
from ddb will call
.Fa command_function .
.Pp
The
.Fn DB_SHOW_COMMAND
and
.Fn DB_SHOW_ALL_COMMAND
are roughly equivalent to
.Fn DB_COMMAND
but in these cases,
.Fa command_name
is a sub-command of the ddb
.Sy show
command and
.Sy show all
command, respectively.
.Pp
The general command syntax:
.Cm command Ns Op Li \/ Ns Ar modifier
.Ar address Ns Op Li , Ns Ar count ,
translates into the following parameters for
.Fa command_function :
.Bl -tag
.It Fa addr
The address passed to the command as an argument.
.It Fa have_addr
A boolean value that is true if the addr field is valid.
.It Fa count
The number of quad words starting at offset
.Fa addr
that the command must process.
.It Fa modif
A pointer to the string of modifiers. That is, a series of symbols
used to pass some options to the command. For example, the
.Sy examine
command will display words in decimal form if it is passed the modifier d.
.El
.Sh EXAMPLE
In your module, the command is declared as:
.Pp
.Bd -literal
DB_COMMAND(mycmd, my_cmd_func)
{
if (have_addr)
db_printf(Calling my command with address %p\\n, addr);
}
.Ed
.Pp
Then, when in ddb:
.Pp
.Bd -literal
.Bf Sy
db mycmd 0x1000
Calling my command with address 0x1000
db
.Ef
.Ed
.Sh SEE ALSO
.Xr ddb 4
.Sh AUTHOR
This manual page was written by
.An Guillaume Ballet Aq [EMAIL PROTECTED] .
And the patch:
--- ./ddb/db_command.c.orig 2008-08-19 00:56:41.0 +0200
+++ ./ddb/db_command.c 2008-08-24 20:59:41.0 +0200
@@ -45,6 +45,7 @@
#include sys/systm.h
#include sys/cons.h
#include sys/watchdog.h
+#include sys/kernel.h
#include ddb/ddb.h
#include ddb/db_command.h
@@ -76,78 +77,68 @@
static db_cmdfcn_t db_watchdog;
/*
+ * Array containing all command 'tables'. See ddb.h.
+ */
+static struct command_table db_command_tables[DB_COMMAND_TABLES_SIZE] = {
+ STAILQ_HEAD_INITIALIZER(db_command_tables[DB_COMMAND_TABLES_DEFAULT]),
+ STAILQ_HEAD_INITIALIZER(db_command_tables[DB_COMMAND_TABLES_SHOW]),
+ STAILQ_HEAD_INITIALIZER(db_command_tables[DB_COMMAND_TABLES_SHOW_ALL])
+};
+
+/*
* 'show' commands
*/
static struct command db_show_all_cmds[] = {
- { procs, db_ps, 0, 0 },
- { (char *)0 }
-};
-
-static struct command_table db_show_all_table = {
- db_show_all_cmds
+ { { NULL }, procs,db_ps, 0, 0 }
};
static struct command db_show_cmds[] = {
- { all,0, 0, db_show_all_table },
- { registers, db_show_regs, 0, 0 },
- { breaks, db_listbreak_cmd, 0, 0 },
- { threads,db_show_threads,0, 0 },
- { (char *)0, }
+ { { NULL }, all, 0, 0,
db_command_tables[DB_COMMAND_TABLES_SHOW_ALL] },
+ { { NULL }, registers,db_show_regs, 0, 0 },
+ { { NULL }, breaks, db_listbreak_cmd, 0, 0 },
+ { { NULL }, threads, db_show_threads,0, 0 }
};
-static struct command_table db_show_table = {
- db_show_cmds,
- SET_BEGIN(db_show_cmd_set),
- SET_LIMIT(db_show_cmd_set)
-};
-
static struct command db_commands[] = {
- { print, db_print_cmd, 0, 0 },
- { p, db_print_cmd, 0, 0 },
- { examine,db_examine_cmd, CS_SET_DOT, 0 },
- { x, db_examine_cmd, CS_SET_DOT, 0 },
- { search, db_search_cmd, CS_OWN|CS_SET_DOT, 0 },
- { set,db_set_cmd, CS_OWN, 0 },
- { write, db_write_cmd, CS_MORE|CS_SET_DOT, 0 },
- { w, db_write_cmd, CS_MORE|CS_SET_DOT, 0 },
- { delete, db_delete_cmd, 0, 0 },
- { d, db_delete_cmd, 0, 0 },
- { break, db_breakpoint_cmd, 0, 0 },
- { b, db_breakpoint_cmd, 0, 0 },
- { dwatch, db_deletewatch_cmd, 0, 0 },
- { watch, db_watchpoint_cmd, CS_MORE,0 },
- { dhwatch,db_deletehwatch_cmd,
FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade
I've been trying to install FreeBSD 7.0-RELEASE amd64 on a Dell M600 Blade but it hangs just after initialising the isa bus. I've tried a number of things and the only thing that I can get to work is the i386 build which boots into the installer without issue. Has anyone had any experience with the Dell M600 blade on amd64 or had the amd64 build hang at this point before. I don't have access to the machines to try new things with ATM as we needed them in production so was forced to install ubuntu to get then live but I should get them back for more testing next week some time so wanted to see if anyone had any experience with this or a similar issue? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW uid logging...
On Mon, Sep 08, 2008 at 04:03:29PM -0400, Dan Mahoney, System Admin wrote: On Mon, 8 Sep 2008, Dan Nelson wrote: In the last episode (Sep 08), Dan Mahoney, System Admin said: I have the following rule set up in ipfw to limit the exposure of bad php scripts and trojans that try to send mail directly. allow tcp from any to any dst-port 25 uid root deny log tcp from any to any dst-port 25 out However, the log messages I get look like this: Sep 8 13:21:11 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:16 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 Which is to say, they don't include the UID -- and I have several hundred sites, each with its own UID. Yes, I could go ahead and set up a thousand deny rules, one for each UID -- but being able to log this info (since it IS being checked) would be great. It should be possible to add a couple more arguments to ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the fw_ugid_cache struct. Then you can edit ipfw_log to print the contents of that struct if ugid_lookup==1. That would result in the logging of uid for any failed packet that had to go through a uid check on the way to the deny rule. Okay, so if it's fairly easy to do, the question would be since I don't feel right hacking in this change myself -- how could I propose this as a feature? It's not a BUG per-se, but I think it could be useful to others as well. send-pr it. Category=kern, Class=change-request. Reference this thread in the Fix section: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/025920.html FWIW, I think it's also a good idea. The output formatting of the log line might need to be adjusted carefully though, since any programs which grep on a very strict regex will start failing. I'm inclined to recommend the string , UID xxx be appended to the existing string, e.g. Sep 8 13:21:11 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0, UID 6592 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW uid logging...
Hi Dan, Dan and the list, On Monday 08 September 2008 22:03:29 Dan Mahoney, System Admin wrote: On Mon, 8 Sep 2008, Dan Nelson wrote: In the last episode (Sep 08), Dan Mahoney, System Admin said: I have the following rule set up in ipfw to limit the exposure of bad php scripts and trojans that try to send mail directly. allow tcp from any to any dst-port 25 uid root deny log tcp from any to any dst-port 25 out However, the log messages I get look like this: Sep 8 13:21:11 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:16 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 Which is to say, they don't include the UID -- and I have several hundred sites, each with its own UID. Yes, I could go ahead and set up a thousand deny rules, one for each UID -- but being able to log this info (since it IS being checked) would be great. It should be possible to add a couple more arguments to ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the fw_ugid_cache struct. Then you can edit ipfw_log to print the contents of that struct if ugid_lookup==1. That would result in the logging of uid for any failed packet that had to go through a uid check on the way to the deny rule. Okay, so if it's fairly easy to do, the question would be since I don't feel right hacking in this change myself -- how could I propose this as a feature? It's not a BUG per-se, but I think it could be useful to others as well. I own a webhosting company and here too every domain gets it's own user, so I like this proposal. I've hacked together a first try, which seems to be working. A patch (against -HEAD) can be found here : http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff Improvements / tips / comments are welcome ;-) -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW uid logging...
In the last episode (Sep 09), Daan Vreeken said: On Monday 08 September 2008 22:03:29 Dan Mahoney, System Admin wrote: On Mon, 8 Sep 2008, Dan Nelson wrote: In the last episode (Sep 08), Dan Mahoney, System Admin said: I have the following rule set up in ipfw to limit the exposure of bad php scripts and trojans that try to send mail directly. allow tcp from any to any dst-port 25 uid root deny log tcp from any to any dst-port 25 out However, the log messages I get look like this: Sep 8 13:21:11 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:16 security.info prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 Which is to say, they don't include the UID -- and I have several hundred sites, each with its own UID. Yes, I could go ahead and set up a thousand deny rules, one for each UID -- but being able to log this info (since it IS being checked) would be great. It should be possible to add a couple more arguments to ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the fw_ugid_cache struct. Then you can edit ipfw_log to print the contents of that struct if ugid_lookup==1. That would result in the logging of uid for any failed packet that had to go through a uid check on the way to the deny rule. Okay, so if it's fairly easy to do, the question would be since I don't feel right hacking in this change myself -- how could I propose this as a feature? It's not a BUG per-se, but I think it could be useful to others as well. Hi Dan, Dan and the list, I own a webhosting company and here too every domain gets it's own user, so I like this proposal. I've hacked together a first try, which seems to be working. A patch (against -HEAD) can be found here: http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff Improvements / tips / comments are welcome ;-) I like it. Maybe print gid as well, since there's an ipfw rule for that too. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
