Re: bin/109334: pkg_add(1) using chroot exits with error if wrong directory
The following reply was made to PR bin/109334; it has been noted by GNATS.
From: Garrett Cooper
To: bug-follo...@freebsd.org, n...@anywi.com
Cc: ra...@freebsd.org
Subject: Re: bin/109334: pkg_add(1) using chroot exits with error if wrong
directory
Date: Tue, 23 Mar 2010 23:52:42 -0700
The original comment states that sysinstall was the primary
consumer of the -C option, and while that may have been the case (once
upon a time), it isn't today according to the code I see in
usr.sbin/sysinstall/package.c .
So what I'm going to propose is the following: change the chroot,
s.t. it only affects the install, operation, which means that instead
of chroot'ing immediately, it'll first try to open the packages, then
prior to executing the install instructions will do the chroot and
will `chdir' to the default prefix (user specified); the default value
will be '/'. That way the chdir back to the starting point will be
sane.
Another less invasive solution would be to merely pop '/' on to
the playpen `stack' for the master in make_playpen, i.e.:
if (!getcwd(cwd, FILENAME_MAX)) {
upchuck("getcwd");
return NULL;
}
if (chdir(pen) == FAIL) { /* <-- 2. source of confusion */
cleanup(0);
errx(2, "%s: can't chdir to '%s'", __func__, pen);
}
strcpy(PenLocation, pen);
return pushPen(cwd); /* <-- 2. source of confusion */
The pseudo code being:
if chroot'ed then push '/' on the stack
else push the current working directory on the stack
The only potential issue I could see is when installing multiple
packages, but that use is tainted anyhow because we chrooted early on,
so the assumption is that the packages have been properly mirrored in
the target environment like they are in the host non-chrooted
environment.
It's up to you guys -- it's a toss-up either way as there will be
some level of confusion, but given that pkg_install is a mess and I
hope to refactor it over the course of the next couple of years, this
will be a minor mess that will need to be cleaned up later.
Thanks,
-Garrett
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/121165: pkg_add(1) prints a weird message: PKG_TMPDIR environment variable to a location with at least 0 bytes
The following reply was made to PR bin/121165; it has been noted by GNATS. From: Garrett Cooper To: bug-follo...@freebsd.org, y...@tsoft.com Cc: Subject: Re: bin/121165: pkg_add(1) prints a weird message: PKG_TMPDIR environment variable to a location with at least 0 bytes Date: Wed, 24 Mar 2010 00:06:09 -0700 --001485e8edde93919604828690c9 Content-Type: text/plain; charset=ISO-8859-1 Apparently the compiler missed the missing format qualifier after the `stack overflow' format string modification because -Wno-format-strings is specified in the default system CFLAGS (not sure where but it's being set in /usr/share/mk...). Sorry for the noise -- here's a correct patch -- I also removed an unneeded newline in an err(3) call. Thanks, -Garrett --001485e8edde93919604828690c9 Content-Type: application/octet-stream; name="bin.121165.diff" Content-Disposition: attachment; filename="bin.121165.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g75shkgx0 SW5kZXg6IGRlbGV0ZS9tYWluLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZGVsZXRlL21haW4uYwkocmV2aXNp b24gMjA1MTU5KQorKysgZGVsZXRlL21haW4uYwkod29ya2luZyBjb3B5KQpAQCAtMzcsNiArMzcs OCBAQAogQm9vbGVhbglSZWN1cnNpdmUJPSBGQUxTRTsKIG1hdGNoX3QJTWF0Y2hUeXBlCT0gTUFU Q0hfR0xPQjsKIAorY2hhcgkqcHJvZ25hbWUJPSBOVUxMOworCiBzdGF0aWMgdm9pZCB1c2FnZSh2 b2lkKTsKIAogc3RhdGljIGNoYXIgb3B0c1tdID0gImFkRGZHaGlucDpydnhYIjsKQEAgLTY3LDYg KzY5LDggQEAKICAgICBjb25zdCBjaGFyICp0bXA7CiAgICAgc3RydWN0IHN0YXQgc3RhdF9zOwog CisgICAgaWYgKChwcm9nbmFtZSA9IGJhc2VuYW1lKGFyZ3ZbMF0pKSA9PSBOVUxMKQorCWVycihF WElUX0ZBSUxVUkUsICJiYXNlbmFtZSIpOwogICAgIHBrZ3MgPSBzdGFydCA9IGFyZ3Y7CiAgICAg d2hpbGUgKChjaCA9IGdldG9wdF9sb25nKGFyZ2MsIGFyZ3YsIG9wdHMsIGxvbmdvcHRzLCBOVUxM KSkgIT0gLTEpCiAJc3dpdGNoKGNoKSB7CkluZGV4OiBjcmVhdGUvbWFpbi5jCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIGNyZWF0ZS9tYWluLmMJKHJldmlzaW9uIDIwNTE1OSkKKysrIGNyZWF0ZS9tYWluLmMJKHdv cmtpbmcgY29weSkKQEAgLTQ1LDYgKzQ1LDcgQEAKIGludAlIZWxwCQk9IEZBTFNFOwogZW51bSB6 aXBwZXIJWmlwcGVyICA9IEJaSVAyOwogCitjaGFyCSpwcm9nbmFtZQk9IE5VTEw7CiAKIHN0YXRp YyB2b2lkIHVzYWdlKHZvaWQpOwogCkBAIC03Miw2ICs3Myw4IEBACiAgICAgaW50IGNoOwogICAg IGNoYXIgKipwa2dzLCAqKnN0YXJ0LCAqdG1wOwogCisgICAgaWYgKChwcm9nbmFtZSA9IGJhc2Vu YW1lKGFyZ3ZbMF0pKSA9PSBOVUxMKQorCWVycihFWElUX0ZBSUxVUkUsICJiYXNlbmFtZSIpOwog ICAgIHBrZ3MgPSBzdGFydCA9IGFyZ3Y7CiAgICAgd2hpbGUgKChjaCA9IGdldG9wdF9sb25nKGFy Z2MsIGFyZ3YsIG9wdHMsIGxvbmdvcHRzLCBOVUxMKSkgIT0gLTEpCiAJc3dpdGNoKGNoKSB7Cklu ZGV4OiB2ZXJzaW9uL21haW4uYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB2ZXJzaW9uL21haW4uYwkocmV2aXNp b24gMjA1MTU5KQorKysgdmVyc2lvbi9tYWluLmMJKHdvcmtpbmcgY29weSkKQEAgLTM2LDYgKzM2 LDggQEAKIEJvb2xlYW4gVXNlSU5ERVhPbmx5ID0gRkFMU0U7CiBCb29sZWFuIFNob3dPcmlnaW4g PSBGQUxTRTsKIAorY2hhcgkqcHJvZ25hbWUJPSBOVUxMOworCiBzdGF0aWMgdm9pZCB1c2FnZSh2 b2lkKTsKIAogc3RhdGljIGNoYXIgb3B0c1tdID0gImRJaGw6TDpxczpYdFRPOm92IjsKQEAgLTY3 LDYgKzY5LDggQEAKIAljbXAgPSB2ZXJzaW9uX21hdGNoKGFyZ3ZbM10sIGFyZ3ZbMl0pOwogCWV4 aXQoY21wID09IDEgPyAwIDogMSk7CiAgICAgfQorICAgIGlmICgocHJvZ25hbWUgPSBiYXNlbmFt ZShhcmd2WzBdKSkgPT0gTlVMTCkKKwllcnIoRVhJVF9GQUlMVVJFLCAiYmFzZW5hbWUiKTsKICAg ICBlbHNlIHdoaWxlICgoY2ggPSBnZXRvcHRfbG9uZyhhcmdjLCBhcmd2LCBvcHRzLCBsb25nb3B0 cywgTlVMTCkpICE9IC0xKSB7CiAJc3dpdGNoKGNoKSB7CiAJY2FzZSAndic6CkluZGV4OiBsaWIv cGVuLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gbGliL3Blbi5jCShyZXZpc2lvbiAyMDUxNTkpCisrKyBsaWIv cGVuLmMJKHdvcmtpbmcgY29weSkKQEAgLTYyLDEwICs2MiwxMSBAQAogCWNsZWFudXAoMCk7CiAJ aHVtYW5pemVfbnVtYmVyKGh1bWJ1Ziwgc2l6ZW9mIGh1bWJ1Ziwgc3osICIiLCBITl9BVVRPU0NB TEUsCiAJICAgIEhOX05PU1BBQ0UpOwotCWVycngoMiwKLSIlczogY2FuJ3QgZmluZCBlbm91Z2gg dGVtcG9yYXJ5IHNwYWNlIHRvIGV4dHJhY3QgdGhlIGZpbGVzLCBwbGVhc2Ugc2V0IHlvdXJcbiIK LSJQS0dfVE1QRElSIGVudmlyb25tZW50IHZhcmlhYmxlIHRvIGEgbG9jYXRpb24gd2l0aCBhdCBs ZWFzdCAlcyBieXRlc1xuIgotImZyZWUiLCBfX2Z1bmNfXywgaHVtYnVmKTsKKwkvKiBYWFg6IE1h aW50YWluIDgwIGNvbHVtbiB3aWR0aCBpbiB0aGUgZXJyb3IgbWVzc2FnZS4gKi8KKwllcnJ4KEVY SVRfRkFJTFVSRSwKKwkgICAgIiVzLiVzOiBub3QgZW5vdWdoIHRlbXBvcmFyeSBzcGFjZSB0byBl eHRyYWN0IHRoZSBmaWxlczsgc2V0IFBLR19UTVBESVIgaW5cbiIKKwkgICAgInlvdXIgZW52aXJv bm1lbnQgdG8gYSBsb2NhdGlvbiB3aXRoIGF0IGxlYXN0ICVzIGJ5dGVzIGZyZWUiLAorCSAgICBw cm9nbmFtZSwgX19mdW5jX18sIGh1bWJ1Zik7CiAJcmV0dXJuIE5VTEw7CiAgICAgfQogICAgIHJl dHVybiBwZW47CkBAIC03OSw3ICs4MCw3IEBACiBwdXNoUGVuKGNvbnN0IGNoYXIgKnBlbikKIHsK ICAgICBpZiAoKytwZGVwdGggPT0gTUFYX1NUQUNLKQotCWVycngoMiwgIiVzOiBzdGFjayBvdmVy Zmxvdy5cbiIsIF9fZnVuY19fKTsKKwllcnJ4KDIsICIlcy4lczogc3RhY2sgb3ZlcmZsb3cuIiwg cHJvZ25hbWUsIF9fZnVuY19fKTsKICAgICBwc3RhY2tbcGRlcHRoXSA9IHN0cmR1cChwZW4pOwog CiAgICAgcmV0dXJuIHBzdGFja1twZGVwdGhdOwpAQCAtMTMxLDkgKzEzMiwxMCBAQAogICAgIGlm IChtaW5fZnJlZShwZW4pIDwgc3opIHsKIAlybWRpcihwZW4pOwogCWNsZWFudXAoMCk7Ci0JZXJy eCgyLCAiJXM6IG5vdCBlbm91Z2ggZnJlZSBzcGFjZSB0byBjcmVhdGUgJyVzJy5cbiIKKwllcnJ4 KDIsICIlcy4lczog
bin/145000: [patch] pkg_create(1) needs realpath(3) on -p argument
>Number: 145000
>Category: bin
>Synopsis: [patch] pkg_create(1) needs realpath(3) on -p argument
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Mar 24 09:10:00 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Garrett Cooper
>Release:9-CURRENT
>Organization:
Cisco Systems, Inc.
>Environment:
FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #5 r205310: Sat Mar 20
01:32:51 PDT 2010 gcoo...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA
amd64
>Description:
When using -p with pkg_create(1) one must specify the full path to the prefix
one is installing in. Example:
$ > desc; > comment; echo "bar" | pkg_create -f - -c comment -d desc -p $PWD
../foo.tbz
$
This doesn't work when using relative paths because it's looking for the files
in the `playpen':
$ > desc; > comment; echo "bar" | pkg_create -f - -c comment -d desc -p .
../foo.tbz
tar: bar: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
pkg_create: make_dist: tar command failed with code 256
$
So my proposal is to change the argument so that it does a realpath on the path
segment, s.t. the prefix is explicitly the path set (which makes sense, as a
relative path would be nothing more than installing into the playpen, which
makes absolutely no sense at all). I verified that this is the behavior that
ports are currently using.
Positive test:
> desc; > comment; echo "bar" |
> /scratch/freebsd/perforce/pkg_install-enhancements/usr.sbin/pkg_install/create/pkg_create
> -f - -c comment -d desc -p . ../foo.tbz
$ bzcat ../foo.tbz
+CONTENTS000644 001750 00 472 11352352166 013107
0ustar00gcooperwheel00 00 @comment PKG_FORMAT_REVISION:1.1
@name foo
@cwd
/scratch/freebsd/perforce/pkg_install-enhancements/tools/regression/usr.sbin/pkg_install/foo
bar
@comment MD5:d41d8cd98f00b204e9800998ecf8427e
@ignore
+COMMENT
@comment MD5:d41d8cd98f00b204e9800998ecf8427e
@ignore
+DESC
@comment MD5:d41d8cd98f00b204e9800998ecf8427e
+COMMENT000644 001750 00 000 11352352166 012737
0ustar00gcooperwheel00 00 +DESC000644 001750 00 000
11352352166 012353 0ustar00gcooperwheel00 00 bar000644 001750 00
000 11352345452 012326 0ustar00gcooperwheel00 00
Negative test:
$ > desc; > comment; echo "bar" |
/scratch/freebsd/perforce/pkg_install-enhancements/usr.sbin/pkg_install/create/pkg_create
-f - -c comment -d desc -p /somewhere/that/does/not/exist ../foo.tbz
pkg_create: couldn't resolve path for prefix: /somewhere/that/does/not/exist:
No such file or directory
The proposed patch also removes an unnecessary `...@cwd .' from created plists
added whenever -p is specified, as I noticed that @cwd was being added twice
when I specified -p (even though I expected it to only be once).
>How-To-Repeat:
Provide a relative path to -p, i.e.:
. , ./ , usr/local, etc
>Fix:
See patch.
Patch attached with submission follows:
//depot/projects/soc2007/gcooper-pkg_install-enhancements-simplified/usr.sbin/pkg_install/create/perform.c#1
-
/scratch/freebsd/perforce/pkg_install-enhancements/usr.sbin/pkg_install/create/perform.c
@@ -208,8 +208,12 @@
read_plist(&plist, pkg_in);
/* Prefix should add an @cwd to the packing list */
-if (Prefix)
- add_plist_top(&plist, PLIST_CWD, Prefix);
+if (Prefix) {
+char resolved_prefix[PATH_MAX];
+if (realpath(Prefix, resolved_prefix) == NULL)
+ err(EXIT_FAILURE, "couldn't resolve path for prefix: %s", Prefix);
+ add_plist_top(&plist, PLIST_CWD, resolved_prefix);
+}
/* Add the origin if asked, at the top */
if (Origin)
@@ -254,7 +258,9 @@
/* mark_plist(&plist); */
/* Now put the release specific items in */
-add_plist(&plist, PLIST_CWD, ".");
+if (!Prefix) {
+ add_plist(&plist, PLIST_CWD, ".");
+}
write_file(COMMENT_FNAME, Comment);
add_plist(&plist, PLIST_IGNORE, NULL);
add_plist(&plist, PLIST_FILE, COMMENT_FNAME);
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/145001: jailed interface lost the ip settings
>Number: 145001 >Category: kern >Synopsis: jailed interface lost the ip settings >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 24 09:30:05 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Robert Kapitany >Release:FreeBSD 8.0-STABLE (VIMAGE) #0 r204860M >Organization: Hungarian Telekom >Environment: FreeBSD virt.lab.t-online.private 8.0-STABLE FreeBSD 8.0-STABLE #0 r204860M: Tue Mar 23 17:14:39 CET 2010 r...@bootm.lab.t-online.private:/usr/obj/usr/src/sys/VIMAGE amd64 >Description: When I add an previously configured network interface to a jail with vnet. It lose the ip settings. Is it the good and expected behavior? >How-To-Repeat: ifconfig pub0 pub0: flags=8843 metric 0 mtu 1500 options=1bb ether 00:18:fe:7a:02:98 inet 10.0.1.1 netmask 0xff00 broadcast 10.0.1.255 media: Ethernet autoselect (1000baseT ) status: active jail -c vnet path=/ jid=666 name=test host.hostname=test.virtlab persist ifconfig pub0 vnet 666 jexec 666 ifconfig lo0: flags=8008 metric 0 mtu 16384 options=3 pub0: flags=8842 metric 0 mtu 1500 options=1bb ether 00:18:fe:7a:02:98 media: Ethernet autoselect (1000baseT ) status: active >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/145001: jailed interface lost the ip settings
The following reply was made to PR kern/145001; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: Robert Kapitany Cc: bug-follo...@freebsd.org Subject: Re: kern/145001: jailed interface lost the ip settings Date: Wed, 24 Mar 2010 09:50:22 + (UTC) On Wed, 24 Mar 2010, Robert Kapitany wrote: > When I add an previously configured network interface to a jail with vnet. > It lose the ip settings. > Is it the good and expected behavior? This is the expected behaviour. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/145004: 8.0-STABLE net.inet.ip.fw.one_pass: 1 not work
>Number: 145004 >Category: misc >Synopsis: 8.0-STABLE net.inet.ip.fw.one_pass: 1 not work >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 24 10:20:02 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Vitaly Moiseev >Release:8.0-STABLE amd64 >Organization: ISP Express LTD >Environment: FreeBSD pppoe-server.expressnikopol.net.ua 8.0-STABLE FreeBSD 8.0-STABLE #6: Wed Mar 24 02:00:10 EET 2010 r...@pppoe-server.expressnikopol.net.ua:/usr/obj/usr/src/sys/PPPOE amd64 >Description: after update to 8.0-STABLE when use ipfw pipe dummynet and variable net.inet.ip.fw.one_pass set to 1, the packet is passed again to the firewall code starting from the next rule. >How-To-Repeat: use ipfw pipe and default to deny ipfw and set net.inet.ip.fw.one_pass=1 - the packets after exit from pipe rules go to next rules. >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/140361: [cpufreq] speed-stepping broken on PhenomII (acpi?)
The following reply was made to PR kern/140361; it has been noted by GNATS. From: Hannes To: bug-follo...@freebsd.org Cc: Subject: Re: kern/140361: [cpufreq] speed-stepping broken on PhenomII (acpi?) Date: Wed, 24 Mar 2010 10:27:34 + *ping* Is there anything I can do to help solve this issue? (still there on a current RELENG_8) Thank you very much, Regards, Hannes ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145004: commit references a PR
The following reply was made to PR misc/145004; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: misc/145004: commit references a PR
Date: Wed, 24 Mar 2010 15:17:08 + (UTC)
Author: luigi
Date: Wed Mar 24 15:16:59 2010
New Revision: 205602
URL: http://svn.freebsd.org/changeset/base/205602
Log:
Honor ip.fw.one_pass when a packet comes out of a pipe without being delayed.
I forgot to handle this case when i did the mtag cleanup three months ago.
PR: 145004
Modified:
head/sys/netinet/ipfw/ip_dn_io.c
Modified: head/sys/netinet/ipfw/ip_dn_io.c
==
--- head/sys/netinet/ipfw/ip_dn_io.c Wed Mar 24 15:16:05 2010
(r205601)
+++ head/sys/netinet/ipfw/ip_dn_io.c Wed Mar 24 15:16:59 2010
(r205602)
@@ -762,7 +762,11 @@ dummynet_io(struct mbuf **m0, int dir, s
*
*/
if (/*dn_cfg.io_fast &&*/ m == *m0 && (dir & PROTO_LAYER2) == 0 ) {
- /* fast io */
+ /* fast io, rename the tag * to carry reinject info. */
+ struct m_tag *tag = m_tag_first(m);
+
+ tag->m_tag_cookie = MTAG_IPFW_RULE;
+ tag->m_tag_id = 0;
io_pkt_fast++;
if (m->m_nextpkt != NULL) {
printf("dummynet: fast io: pkt chain detected!\n");
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145004: 8.0-STABLE net.inet.ip.fw.one_pass: 1 not work
Synopsis: 8.0-STABLE net.inet.ip.fw.one_pass: 1 not work State-Changed-From-To: open->closed State-Changed-By: luigi State-Changed-When: Wed Mar 24 15:20:12 UTC 2010 State-Changed-Why: fixed in r205601(HEAD) and r205602(RELENG_8) http://www.freebsd.org/cgi/query-pr.cgi?pr=145004 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145004: commit references a PR
The following reply was made to PR misc/145004; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: misc/145004: commit references a PR
Date: Wed, 24 Mar 2010 15:20:04 + (UTC)
Author: luigi
Date: Wed Mar 24 15:19:47 2010
New Revision: 205603
URL: http://svn.freebsd.org/changeset/base/205603
Log:
MFC 205602:
Honor ip.fw.one_pass when a packet comes out of a pipe without being delayed.
I forgot to handle this case when i did the mtag cleanup three months ago.
I am merging immediately because this bugfix is important for
people using RELENG_8.
PR: 145004
Modified:
stable/8/sys/netinet/ipfw/ip_dn_io.c
Modified: stable/8/sys/netinet/ipfw/ip_dn_io.c
==
--- stable/8/sys/netinet/ipfw/ip_dn_io.c Wed Mar 24 15:16:59 2010
(r205602)
+++ stable/8/sys/netinet/ipfw/ip_dn_io.c Wed Mar 24 15:19:47 2010
(r205603)
@@ -762,7 +762,11 @@ dummynet_io(struct mbuf **m0, int dir, s
*
*/
if (/*dn_cfg.io_fast &&*/ m == *m0 && (dir & PROTO_LAYER2) == 0 ) {
- /* fast io */
+ /* fast io, rename the tag * to carry reinject info. */
+ struct m_tag *tag = m_tag_first(m);
+
+ tag->m_tag_cookie = MTAG_IPFW_RULE;
+ tag->m_tag_id = 0;
io_pkt_fast++;
if (m->m_nextpkt != NULL) {
printf("dummynet: fast io: pkt chain detected!\n");
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/145001: jailed interface lost the ip settings
Synopsis: jailed interface lost the ip settings State-Changed-From-To: open->closed State-Changed-By: remko State-Changed-When: Wed Mar 24 15:51:59 UTC 2010 State-Changed-Why: This is intended behaviour as Bjoern mentioned, in any case questions are not PR tickets.. Thanks for trying to make FreeBSD Better! http://www.freebsd.org/cgi/query-pr.cgi?pr=145001 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/74387: mount(8) linprocfs can be mounted on top of itself many times
The following reply was made to PR bin/74387; it has been noted by GNATS. From: Alexander Best To: Cc: Subject: Re: bin/74387: mount(8) linprocfs can be mounted on top of itself many times Date: Wed, 24 Mar 2010 18:09:59 +0100 (CET) this pr is no longer reproducible under HEAD (r205561). `cat /etc/fstab|grep linprocfs`: linprocfs /compat/linux/proc linprocfs rw 0 0 linprocfs /usr/local/gentoo-stage3/proc linprocfs rw 0 0 `mount|wc`: 11 55 491 `for i in `jot - 1 10`; do mount -a; done` `mount|wc`: 11 55 491 sbin/mount/mount.c:466 has a comment saying: /* The user may have specified a symlink in fstab, resolve the path */ so ismounted() takes care of this now. the commit that fixed this was r154512 (HEAD, stable8 and stable7). it's been mfc'ed to stable6 in r154774. so this pr can be closed. -- Alexander Best ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/74387: mount(8) linprocfs can be mounted on top of itself many times
Synopsis: mount(8) linprocfs can be mounted on top of itself many times State-Changed-From-To: analyzed->closed State-Changed-By: gavin State-Changed-When: Wed Mar 24 17:21:06 UTC 2010 State-Changed-Why: Alexander Best reports that this was fixed some time ago and can no longer be reproduced. http://www.freebsd.org/cgi/query-pr.cgi?pr=74387 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/121165: pkg_add(1) prints a weird message: PKG_TMPDIR environment variable to a location with at least 0 bytes
On Tue, 23 Mar 2010, Garrett Cooper wrote: On Tue, Mar 23, 2010 at 12:26 PM, Bruce Evans wrote: On Mon, 22 Mar 2010, Garrett Cooper wrote: ? ?Functions as expected provided test added in http://p4web.freebsd.org/chv.cgi?CH=175930 ; I'm just making one minor style change from the previous patch so that errx(3) in find_play_pen exits with EXIT_FAILURE instead of 2 (I agree that EXIT_FAILURE is synonymous to 2, but for it's more readable and consistent as EXIT_FAILURE). EXIT_FAILURE is 1. Excellent point -_-... should I just revert this then or leave it as-is? Depends on whether distinguishing the exit code 2 from the exit code 1 is important. Normally it isn't, but sometimes 2 is documented and then at least the documentation should be changed too. BTW, I glanced at this because it looked a bit like use of sysexits and I don't like sysexits. But sysexits exit codes start at 64 and are almost perfectly undocumented in utilities that use sysexits. I don't mind using the Standard C EXIT_SUCCESS and EXIT_FAILURE although these are just aliases for 0 and 1 and these aliases are also almost perfectly undocumented (most man pages use the mdoc macro ".Ex -std" which expands to "The utility exits 0 on success, and >0 if an error occurs." POSIX also mostly says 0/>0. Thus the values in sysexits are allowed, but know one knows what they mean. Bruce___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
conf/145009: rc.conf should allow mac label configuration
>Number: 145009
>Category: conf
>Synopsis: rc.conf should allow mac label configuration
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Wed Mar 24 18:50:01 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Michael Reynolds
>Release:8.0-STABLE
>Organization:
>Environment:
n/a
>Description:
rc.conf, via rc.subr, should allow service specific labels to be set, so as to
efficiently handle security, and ensure a working machine after enabling MAC.
>How-To-Repeat:
>Fix:
Apply the affixed patch, add this (as an example) to your rc.conf:
auditd_label="biba/high,lomac/high,mls/high,partition/equal"
Patch attached with submission follows:
--- etc/rc.subr 2009-12-30 14:25:40.0 -0500
+++ /etc/rc.subr2010-03-18 11:39:16.0 -0400
@@ -646,7 +646,8 @@
fi
eval _chdir=\$${name}_chdir _chroot=\$${name}_chroot \
_nice=\$${name}_nice_user=\$${name}_user \
- _group=\$${name}_group _groups=\$${name}_groups
+ _group=\$${name}_group _groups=\$${name}_groups \
+ _label=\$${name}_label
if [ -n "$_user" ]; then# unset $_user if running as that user
if [ "$_user" = "$(eval $IDCMD)" ]; then
@@ -726,10 +727,12 @@
if [ -n "$_chroot" ]; then
_doit="\
${_nice:+nice -n $_nice }\
+${_label:+setpmac $_label }\
chroot ${_user:+-u $_user }${_group:+-g $_group }${_groups:+-G $_groups }\
$_chroot $command $rc_flags $command_args"
else
_doit="\
+${_label:+setpmac $_label }\
${_chdir:+cd $_chdir && }\
$command $rc_flags $command_args"
if [ -n "$_user" ]; then
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
gnu/145010: cpio: buffer overflow in rmt client
>Number: 145010
>Category: gnu
>Synopsis: cpio: buffer overflow in rmt client
>Confidential: no
>Severity: serious
>Priority: high
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Mar 24 19:00:11 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Christian Weisgerber
>Release:FreeBSD 7.3-PRERELEASE amd64
>Organization:
>Environment:
System: FreeBSD lorvorc.mips.inka.de 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #0:
Sat Mar 20 13:36:54 CET 2010
na...@lorvorc.mips.inka.de:/usr/obj/usr/src/sys/GENERIC amd64
This applies to all branches of FreeBSD.
>Description:
CVE-2010-0624
Heap-based buffer overflow in the rmt_read__ function in
lib/rtapelib.c in the rmt client functionality in GNU tar before
1.23 and GNU cpio before 2.11 allows remote rmt servers to cause
a denial of service (memory corruption) or possibly execute
arbitrary code by sending more data than was requested, related
to archive filenames that contain a : (colon) character.
Also see the original report:
http://www.agrs.tu-berlin.de/index.php?id=78327
>How-To-Repeat:
>Fix:
Index: contrib/cpio/lib/rtapelib.c
===
RCS file: /home/ncvs/src/contrib/cpio/lib/rtapelib.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 rtapelib.c
--- contrib/cpio/lib/rtapelib.c 1 Oct 2005 04:37:06 - 1.1.1.1
+++ contrib/cpio/lib/rtapelib.c 24 Mar 2010 18:55:27 -
@@ -570,7 +570,8 @@
sprintf (command_buffer, "R%lu\n", (unsigned long) length);
if (do_command (handle, command_buffer) == -1
- || (status = get_status (handle)) == SAFE_READ_ERROR)
+ || (status = get_status (handle)) == SAFE_READ_ERROR
+ || status > length)
return SAFE_READ_ERROR;
for (counter = 0; counter < status; counter += rlen, buffer += rlen)
@@ -706,6 +707,12 @@
|| (status = get_status (handle), status == -1))
return -1;
+ if (status > sizeof (struct mtop))
+ {
+ errno = EOVERFLOW;
+ return -1;
+ }
+
for (; status > 0; status -= counter, argument += counter)
{
counter = safe_read (READ_SIDE (handle), argument, status);
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: gnu/145010: cpio: buffer overflow in rmt client
Synopsis: cpio: buffer overflow in rmt client Responsible-Changed-From-To: freebsd-bugs->secteam Responsible-Changed-By: delphij Responsible-Changed-When: Wed Mar 24 19:23:25 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=145010 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/145013: [patch] ru/security/security.sgml: MFen 1.209 -> 1.211
>Number: 145013 >Category: misc >Synopsis: [patch] ru/security/security.sgml: MFen 1.209 -> 1.211 >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 24 20:50:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: pluknet >Release: >Organization: >Environment: >Description: The attached patch brings the Russian Security page up to date. >How-To-Repeat: >Fix: Patch attached with submission follows: --- www.orig/ru/security/security.sgml 2010-03-24 21:55:08.0 +0300 +++ www/ru/security/security.sgml 2010-03-24 22:07:47.0 +0300 @@ -4,7 +4,7 @@ $FreeBSD: www/ru/security/security.sgml,v 1.20 2010/02/20 23:37:15 gabor Exp $ $FreeBSDru: frdp/www/ru/security/security.sgml,v 1.33 2004/09/21 07:31:12 den Exp $ - Original revision: 1.209 + Original revision: 1.211 --> 7.2-RELEASE ïÂÙÞÎÙÊ 4 ÍÁÑ 2009 - 31 ÍÁÑ 2010 + 30 ÉÀÎÑ 2010 + + + RELENG_7_3 + 7.3-RELEASE + òÁÓÛÉÒÅÎÎÙÊ + 23 ÍÁÒÔÁ 2010 + 31 ÍÁÒÔÁ 2012 RELENG_8 @@ -298,6 +305,13 @@ 25 ÎÏÑÂÒÑ 2009 30 ÎÏÑÂÒÑ 2010 + + RELENG_8_1 + 8.1-RELEASE + òÁÓÛÉÒÅÎÎÙÊ + ÐÏËÁ ÎÅÔ + ÒÅÌÉÚ + 2 ÇÏÄÁ + âÏÌÅÅ ÓÔÁÒÙÅ ÒÅÌÉÚÙ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÀÔÓÑ, Á ÉÈ ÐÏÌØÚÏ×ÁÔÅÌÑÍ ÎÁÓÔÏÑÔÅÌØÎÏ >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145013: [patch] ru/security/security.sgml: MFen 1.209 -> 1.211
The following reply was made to PR misc/145013; it has been noted by GNATS. From: pluknet To: bug-follo...@freebsd.org, pluk...@gmail.com Cc: Subject: Re: misc/145013: [patch] ru/security/security.sgml: MFen 1.209 -> 1.211 Date: Wed, 24 Mar 2010 23:58:22 +0300 I'm sorry. Change to `doc' category requested. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: docs/145013: [patch] ru/security/security.sgml: MFen 1.209 -> 1.211
Synopsis: [patch] ru/security/security.sgml: MFen 1.209 -> 1.211 Responsible-Changed-From-To: freebsd-bugs->freebsd-doc Responsible-Changed-By: remko Responsible-Changed-When: Wed Mar 24 21:08:32 UTC 2010 Responsible-Changed-Why: reassign to docteam http://www.freebsd.org/cgi/query-pr.cgi?pr=145013 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: conf/145009: [patch] rc.subr(8): rc.conf should allow mac label configuration
Old Synopsis: rc.conf should allow mac label configuration New Synopsis: [patch] rc.subr(8): rc.conf should allow mac label configuration Responsible-Changed-From-To: freebsd-bugs->freebsd-rc Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 24 23:21:15 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=145009 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
