From owner-p4-projects@FreeBSD.ORG Tue Jan 27 18:46:38 2009 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 837541065672; Tue, 27 Jan 2009 18:46:38 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4138D106566B for ; Tue, 27 Jan 2009 18:46:38 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 2E24F8FC13 for ; Tue, 27 Jan 2009 18:46:38 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id n0RIkc5Z068619 for ; Tue, 27 Jan 2009 18:46:38 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id n0RIkcXQ068617 for perforce@freebsd.org; Tue, 27 Jan 2009 18:46:38 GMT (envelope-from rene@FreeBSD.org) Date: Tue, 27 Jan 2009 18:46:38 GMT Message-Id: <200901271846.n0RIkcXQ068617@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to rene@FreeBSD.org using -f From: Rene Ladan To: Perforce Change Reviews Cc: Subject: PERFORCE change 156752 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2009 18:46:39 -0000 http://perforce.freebsd.org/chv.cgi?CH=156752 Change 156752 by rene@rene_self on 2009/01/27 18:46:16 IFC Affected files ... .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/security/chapter.sgml#10 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/pmake/basics/chapter.sgml#2 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/porters-handbook/book.sgml#19 integrate .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml#17 integrate .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/eresources/chapter.sgml#17 integrate .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/share/sgml/mailing-lists.ent#13 integrate .. //depot/projects/docproj_nl/share/pgpkeys/rafan.key#2 integrate .. //depot/projects/docproj_nl/www/en/community.xsl#4 integrate .. //depot/projects/docproj_nl/www/en/donations/wantlist.sgml#9 integrate .. //depot/projects/docproj_nl/www/en/smp/index.sgml#3 integrate .. //depot/projects/docproj_nl/www/share/sgml/events.xml#13 integrate .. //depot/projects/docproj_nl/www/share/sgml/libcommon.xsl#4 integrate Differences ... ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/security/chapter.sgml#10 (text+ko) ==== @@ -1,7 +1,7 @@ @@ -594,25 +594,65 @@ use a KLD module to install his own bpf device, or other sniffing device, on a running kernel. To avoid these problems you have to - run the kernel at a higher secure level, at least securelevel 1. - The securelevel can be set with a sysctl on - the kern.securelevel variable. Once you have - set the securelevel to 1, write access to raw devices will be - denied and special chflags flags, - such as schg, - will be enforced. You must also ensure that the - schg flag is set on critical startup binaries, - directories, and script files — everything that gets run up - to the point where the securelevel is set. This might be overdoing - it, and upgrading the system is much more difficult when you - operate at a higher secure level. You may compromise and run the - system at a higher secure level but not set the - schg flag for every system file and directory - under the sun. Another possibility is to simply mount - / and /usr read-only. - It should be noted that being too draconian in what you attempt to - protect may prevent the all-important detection of an - intrusion. + run the kernel at a higher secure level, at least securelevel 1. + + The secure level of the kernel can be set in a variety of ways. + The simplest way of raising the secure level of a running kernel is + through a sysctl on + the kern.securelevel kernel variable: + + &prompt.root; sysctl kern.securelevel=1 + + By default, the &os; kernel boots with a secure level of -1. The + secure level will remain at -1 unless it is altered, either by the + administrator or by &man.init.8; because of a setting in the start up + scripts. The secure level may be raised during system startup by + setting the kern_securelevel_enable variable to + YES in the /etc/rc.conf file, + and the value of the kern_securelevel variable to + the desired secure level. + + The default secure level of an &os; system right after the startup + scripts are done is -1. This is called insecure mode + because immutable file flags may be turned off, all devices may be + read from or written to, and so on. + + Once the secure level is set to 1 or a higher value, the + append-only and immutable files are honored, they cannot be turned + off, and access to raw devices will be denied. Higher levels restrict + even more operations. For a full description of the effect of various + secure levels, please read the &man.security.7; manual page (or the + manual page of &man.init.8; in releases older than &os; 7.0). + + + Bumping the secure level to 1 or higher may cause a few problems + to X11 (access to /dev/io will be blocked), or + to the installation of &os; build from source + (the installworld part of the process needs + to temporarily reset the append-only and immutable flags of some + files), and in a few other cases. Sometimes, as in the case of X11, + it may be possible to work around this by starting &man.xdm.1; + pretty early in the boot process, when the securelevel is still low + enough. Workarounds like this may not be possible for all secure + levels or for all the potential restrictions they enforce. A bit of + forward planning is a good idea. Understanding the restrictions + imposed by each secure level is important as they severly diminish + the ease of system use. It will also make choosing a default + setting much simpler and prevent any surprises. + + + If the kernel's secure level is raised to 1 or a higher value, it + may be useful to set the schg flag on critical + startup binaries, directories, and script files (i.e. everything that + gets run up to the point where the securelevel is set). This might be + overdoing it, and upgrading the system is much more difficult when it + operates at a high secure level. A less strict compromise is to run + the system at a higher secure level but skip setting set + the schg flag for every system file and directory + under the sun. Another possibility is to simply + mount / and /usr read-only. + It should be noted that being too draconian about what is permitted + may prevent the all-important detection of an intrusion. ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/pmake/basics/chapter.sgml#2 (text+ko) ==== @@ -1,5 +1,5 @@ @@ -83,9 +83,6 @@ - - - : @@ -178,9 +175,6 @@ - - - {} @@ -1019,9 +1013,6 @@ - - - a ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/porters-handbook/book.sgml#19 (text+ko) ==== @@ -1,7 +1,7 @@ A little background first. OpenBSD has a neat feature - inside both DISTFILES and - PATCHFILES variables, both files and - patches can be postfixed with :n - identifiers where n both can be + inside the DISTFILES and + PATCHFILES variables which allows files and + patches to be postfixed with :n + identifiers. Here, n can be both [0-9] and denote a group designation. For example: @@ -2436,7 +2436,7 @@ as hell where beta is carried by all sites in MASTER_SITES, and alpha can only be found in the 20th - site. It would be such a waste to check all of them if + site. It would be such a waste to check all of them if the maintainer knew this beforehand, would it not? Not a good start for that lovely weekend! @@ -3121,7 +3121,7 @@ challenge for port maintainers section. Changes to the port will be sent to the maintainer of - a port for a review and an approval before being committed. + a port for review and approval before being committed. If the maintainer does not respond to an update request after two weeks (excluding major public holidays), then that is considered a maintainer timeout, and the @@ -3137,8 +3137,8 @@ to better match existing policies and style of the Ports Collection without explicit blessing from the submitter. Also, large infrastructural changes can result in - a port being modified without maintainer's consent. - This kind of changes will never affect the port's + a port being modified without the maintainer's consent. + These kinds of changes will never affect the port's functionality. The &a.portmgr; reserves the right to revoke or override @@ -4090,7 +4090,7 @@ Two macros exists for this situation. The advantage of using these macros instead of cp is that they guarantee - proper file ownership and permissions on target files. First macro, + proper file ownership and permissions on target files. The first macro, COPYTREE_BIN, will set all the installed files to be executable, thus being suitable for installing into PREFIX/bin. The second @@ -8645,6 +8645,11 @@ The packing list still has to be tidied up by hand as stated above. + Another tool that might be used to create an initial + pkg-plist is ports-mgmt/genplist. As with any + automated tool, the resulting pkg-plist + should be checked and manually edited as needed. @@ -11882,7 +11887,7 @@ 7.0-CURRENT after RFC 3678 API support added to the IPv4 stack. - Legacy RFC 1724 behaviour of the IP_MULTICAST_IF + Legacy RFC 1724 behavior of the IP_MULTICAST_IF ioctl has now been removed; 0.0.0.0/8 may no longer be used to specify an interface index. struct ipmreqn should be used instead. ==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml#17 (text+ko) ==== @@ -1,7 +1,7 @@ + uid Rong-En Fan -uid Rong-En Fan (CSIE, NTU) uid Rong-En Fan -sub 2048g/CC9AC94F 2004-06-04 [expires: 2009-06-03] +sub 2048g/42A8637E 2009-01-25 [expires: 2012-07-08] ]]> ==== //depot/projects/docproj_nl/www/en/community.xsl#4 (text+ko) ==== @@ -6,7 +6,7 @@ ]> - + @@ -47,7 +47,9 @@

There are more than one hundred mailing - lists and several , dozens of web-based forums, and + several newsgroups available. There are over - + @@ -404,6 +404,13 @@ 802.11a (5GHz) accesspoint with WPA2 Hopefully improve WiFi in 2.4GHz-infested apartment building. + + + rui + Portugal + Intel Mac, possibly Mac Mini for a small shipment fee + EFI support under FreeBSD and other Mac development work. + &footer; ==== //depot/projects/docproj_nl/www/en/smp/index.sgml#3 (text+ko) ==== @@ -1,6 +1,6 @@ - + @@ -201,29 +201,29 @@ primitives can be found here:


-

In addition, the old SPL man page may be of interest, as it reflects the previous SMP synchronization model.

+

In addition, the old SPL man page may be of interest, as it reflects the previous SMP synchronization model.

  • ==== //depot/projects/docproj_nl/www/share/sgml/events.xml#13 (text+ko) ==== @@ -10,10 +10,34 @@ - $FreeBSD: www/share/sgml/events.xml,v 1.66 2009/01/06 13:45:10 danger Exp $ + $FreeBSD: www/share/sgml/events.xml,v 1.67 2009/01/24 19:07:08 danger Exp $ + + Network-related Bugathon #6 + http://wiki.freebsd.org/Bugathons/January2009 + + 2009 + 1 + 30 + + + 2009 + 2 + 1 + + + A bugathon is an event coordinated by the &os; + bugbusting team. Bugathons are held on IRC (in the + #freebsd-bugbusters channel of EFnet), and are attended by any + interested &os; developers and contributors during a week-end. + They focus on closing as many problem reports and fixing as many + bugs as possible. The plan for the sixth bugathon is to work + through the all network-related problem reports in &os;'s GNATS + database. + + FOSDEM '09 http://fosdem.org/2009/ ==== //depot/projects/docproj_nl/www/share/sgml/libcommon.xsl#4 (text+ko) ==== @@ -1,7 +1,7 @@ - +
    - (, ) + + (, ) +